ETSI TS 123 205 V9.2.0 {201104) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 
Bearer-independent circuit-switched core network; 

Stage 2 

(3GPP TS 23.205 version 9.2.0 Release 9) 




3GPP TS 23.205 version 9.2.0 Release 9 



1 



ETSI TS 123 205 V9.2.0 (2011-04) 



Reference 
RTS/TSGC-0423205V920 

Keywords 
UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 



Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at 
http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 201 1 . 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 
for the benefit of its Members and of the 3GPP Organizational Partners. 
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



2 



ETSI TS 123 205 V9.2.0 (2011-04) 



Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home . asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



3 



ETSI TS 123 205 V9.2.0 (2011-04) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 15 

1 Scope 16 

2 References 16 

3 Symbols and abbreviations 18 

3.1 Symbols 18 

3.2 Abbreviations 18 

3 . 3 Definitions 19 

4 Main Concepts 19 

4.1 General 19 

4.2 Bearer-Independent Call Control 19 

4.3 H.248/MEGACO 20 

5 General Circuit Switched Core Network Domain Architecture 20 

5 . 1 Logical Architecture 20 

5.1.1 CS Core Network Nodes 20 

5.1.1.1 MSC Server 20 

5.1.1.2 GMSC Server 20 

5.1.1.3 Media Gateway 20 

5.1.2 CS Core Network Interfaces and Reference Points 21 

5.1.2.1 Mc Interface 21 

5.1.2.2 Nc Interface 21 

5.1.2.3 Nb Interface 21 

5 . 2 Network Interworking 21 

5.2.1 Interworking on the Nc Reference Point 21 

5.2.2 Interworking on the Nb Reference Point 21 

6 Call Establishment 21 

6. 1 Basic Mobile Originating Call 21 

6.1.1 Forward bearer establishment 21 

6.1.1.1 MGW selection 21 

6.1.1.2 Initial addressing 22 

6.1.1.3 Network side bearer establishment 22 

6.1.1.4 Access bearer assignment 22 

6. 1 . 1 .5 Framing protocol initialisation 22 

6. 1 . 1 .6 Confirmation of bearer estabhshment 22 

6.1.1.7 Through-Connection 23 

6.1.1.8 Interworking function 23 

6. 1 . 1 .9 Codec handling 23 

6.1.1.10 Voice Processing function 23 

6.1.1.11 Failure handling in MSC server 23 

6.1.1.12 Example 23 

6. 1 .2 Backward bearer establishment 26 

6.1.2.1 MGW selection 26 

6.1.2.2 Network side bearer establishment 26 

6.1.2.3 Initial addressing 26 

6. 1 .2.4 Access bearer assignment 27 

6. 1 .2.5 Framing protocol initialisation 27 

6. 1 .2.6 Confirmation of bearer estabhshment 27 

6. 1 .2.7 Through-Connection 27 

6. 1 .2.8 Interworking function 27 

6.1.2.9 Codec handling 28 

6.1.2.10 Voice Processing function 28 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



4 



ETSI TS 123 205 V9.2.0 (2011-04) 



6. 1 .2. 1 1 Failure handling in MSG server 28 

6.1.2.12 Example 28 

6.1.3 Originating Call Establishment For lu Interface on IP 30 

6. 1 .4 Forward bearer establishment with Trace Session Activation 31 

6. 1 .4. 1 Trace activation 3 1 

6.1.4.2 Example 32 

6. 1 .5 Originating Call Establishment for A interface over IP 34 

6.2 B asic Mobile Terminating Call 35 

6.2.1 Forward be arer e stablishment 35 

6.2. 1. 1 GMSC server 35 

6.2.1.1.1 MOW selection 35 

6.2.1.1.2 Initial addressing 36 

6.2.1.1.3 Outgoing side bearer establishment 36 

6.2. 1 . 1 .4 Incoming side bearer establishment 36 

6.2.1.1.5 Framing protocol initialisation 36 

6.2.1.1.6 Through-Connection 36 

6.2. 1 . 1 .7 Confirmation of bearer estabUshment 36 

6.2. 1 . 1 .8 Voice Processing function 37 

6.2.1 .1 .9 Failure handling in GMSC server 37 

6.2.1.2 MSC server 37 

6.2.1.2.1 Paging 37 

6.2.1.2.2 Call setup 37 

6.2.1.2.3 MOW selection 37 

6.2.1.2.4 Network side bearer establishment 37 

6.2.1.2.5 Access bearer assignment 37 

6.2.1.2.6 Framing protocol initialisation 38 

6.2.1.2.7 Called party alerting 38 

6.2.1.2.8 Called party answer 38 

6.2.1.2.9 Through-Connection 38 

6.2. 1 .2. 1 Interworking function 39 

6.2.1.2.11 Codec handling 39 

6.2.1.2.12 Voice Processing function 39 

6.2.1.2.13 Failure handling in MSC server 39 

6.2.1.2.14 Example 39 

6.2.2 Backward bearer establishment 42 

6.2.2.1 GMSC server 42 

6.2.2.1.1 MGW selection 42 

6.2.2.1.2 Outgoing side bearer establishment 42 

6.2.2.1.3 Initial addressing 42 

6.2.2. 1 .4 Incoming side bearer establishment 42 

6.2.2. 1 .5 Framing protocol initialisation 42 

6.2.2.1.6 Through-Connection 43 

6.2.2. 1 .7 Confirmation of bearer estabUshment 43 

6.2.2.1.8 Voice Processing function 43 

6.2.2. 1 .9 Failure handling in GMSC server 43 

6.2.2.2 MSC server 43 

6.2.2.2.1 Paging 43 

6.2.2.2.2 Call setup 43 

6.2.2.2.3 MGW selection 44 

6.2.2.2.3 Network side bearer establishment 44 

6.2.2.2.4 Access bearer assignment 44 

6.2.2.2.5 Framing protocol initialisation 44 

6.2.2.2.6 Called party alerting 45 

6.2.2.2.7 Called party answer 45 

6.2.2.2.8 Through-Connection 45 

6.2.2.2.9 Interworking function 45 

6.2.2.2.10 Codec handUng 45 

6.2.2.2.11 Voice Processing function 45 

6.2.2.2.12 Failure handling in MSC server 45 

6.2.2.2.13 Example 45 

6.2.3 Terminating Call Establishment For lu Interface on IP 49 

6.2.4 Terminating Call Establishment For A Interface over IP 51 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 5 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

7 Call Clearing 51 

7.1 Network Initiated 52 

7.1.1 GMSC server 52 

7.1.1.1 Call clearing from the incoming side 52 

7.1.1.2 Call clearing to the outgoing side 52 

7.1.2 MSC server 52 

7.1.2.1 Call clearing from the network side 52 

7.1 .2.2 Call clearing to the UE 52 

7.1.2.3 Example 53 

7.2 User Initiated 54 

7.2.1 Void 55 

7.2.2 MSC server 55 

7.2.2.1 all clearing from the UE 55 

7.2.2.2 Call clearing to the network side 55 

7.2.2.3 Example 55 

7.3 (G)MSC server Initiated 56 

7.3.1 GMSC server 56 

7.3.1.1 Call clearing to the destination side 56 

7.3.1.2 Call clearing to the originating side 56 

7.3.2 MSC server 57 

7.3.2.1 Call clearing to the UE 57 

7.3.2.2 Call clearing to the network side 57 

7.3.2.3 Example 57 

7.4 MGW Initiated 59 

7.4.1 GMSC server 59 

7.4.1.1 Bearer released on the destination side 59 

7.4. 1 .2 Bearer released on the originating side 59 

7.4.2 MSC server 59 

7.4.2.1 Bearer released on the access side 59 

7.4.2.2 Bearer released on the network side 59 

7.4.2.3 Example 59 

7.5 Call Clearing for lu Interface on IP 61 

8 Handover/Relocation 63 

8.1 UMTS to UMTS 63 

8.1.1 Intra-MSC SRNS/SBSS Relocation 63 

8.1.1.1 Relocation Required 64 

8.1.1.2 Relocation Command/Relocation Detect 64 

8.1.1.3 Relocation Complete 64 

8.1.1.4 Interworking function 64 

8.1.1.5 Codec handling 64 

8.1.1.6 Voice Processing function 64 

8.1.1.7 Handhng of multiple bearers (multicall) 64 

8.1.1.8 Failure HandUng in MSC server 64 

8.1.1.9 Example 64 

8.1.2 Basic Inter-MSC SRNS/SBSS Relocation 67 

8.1.2.1 MSC-A/MGW-A 67 

8.1.2.1.1 Relocation Required 67 

8.1.2.1.2 Bearer establishment between MGW-A and MGW-B 67 

8. 1 .2. 1 .3 Relocation Command/Relocation Detect 67 

8.1.2.1.4 Relocation Complete 67 

8.1.2.1.5 Interworking function 67 

8.1.2.1.6 Codec handling 67 

8. 1 .2. 1 .7 Voice Processing function 67 

8.1.2.1.8 Handling of multiple bearers (multicall) 68 

8.1.2.1.9 Failure Handling in MSC server 68 

8.1.2.2 MSC-B/MGW-B 68 

8.1.2.2.1 MGW selection 68 

8.1.2.2.2 Bearer establishment towards RNC-B 68 

8.1 .2.2.3 Bearer establishment between MGW-A and MGW-B 68 

8.1.2.2.4 Codec handling 68 

8. 1 .2.2.5 Voice Processing function 68 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



6 



ETSI TS 123 205 V9.2.0 (2011-04) 



8.1.2.2.6 Handling of multiple bearers (multicaU) 68 

8.1.2.2.7 Failure Handling in MSG server 68 

8.1.2.2.8 Example 69 

8.1.3 Subsequent Inter-MSC SRNS/SBSS Relocation back to the Anchor MSG 71 

8.1.3.1 MSG-A/MGW-A 71 

8.1.3.1.1 Relocation Request 71 

8.1.3.1.2 Relocation Gommand/Relocation Detect 71 

8.1.3.1.3 Relocation Gomplete 72 

8.1.3.1.4 Interworking function 72 

8.1.3.1.5 GodechandUng 72 

8.1.3.1.6 Voice Processing function 72 

8. 1 .3. 1 .7 Handling of multiple bearers (multicaU) 72 

8.1.3.1.8 Failure Handling in MSG server 72 

8.1.3.2 MSG-B/MGW-B 72 

8.1.3.2.1 Relocation Required 72 

8.1.3.2.2 Relocation Gomplete 72 

8.1.3.2.3 Release of bearer towards MGW-A 72 

8.1.3.2.4 Handling of multiple bearers (multicaU) 73 

8.1.3.2.5 Example 73 

8.1.4 Subsequent Inter-MSG SRNS/SBSS Relocation to a third MSG 75 

8.1.5 SRNS/SBSS Relocation with lu on IP 75 

8.1.6 Intra-MSG enhanced SRNS Relocation 76 

8.1.6.1 Introduction 76 

8.1 .6.2 Enhanced Relocation Gomplete Request 76 

8.1.6.3 Enhanced Relocation Gomplete Gonfirm 77 

8.1 .6.4 Interworking function 77 

8. 1 .6.5 Godec handling 77 

8.1.6.6 Voice Processing function 77 

8.1 .6.7 Handling of multiple bearers (multicaU) 77 

8.1 .6.8 Failure Handling in MSG server 77 

8.1.6.9 Example 77 

8.1.7 Intra-MSG enhanced SRNS Relocation with lu on IP 79 

8.2 UMTS to GSM 80 

8.2.1 Intra-MSG UMTS to GSM Handover 80 

8.2.1.1 Relocation Required 80 

8.2.1.2 Handover Request Acknowledge 81 

8.2.1.3 Relocation Gommand/Handover Detect 81 

8.2.1.4 Handover Gomplete 81 

8.2.1.5 Interworking function 81 

8.2.1.6 Voice Processing function 81 

8.2.1.7 Handling of multiple bearers (multicaU) 81 

8.2.1.8 Failure HandUng in MSG server 81 

8.2.1.9 Example 81 

8.2.1 .10 Intra-MSG UMTS to GSM Handover for A interface over IP 84 

8.2.2 Basic Inter-MSG UMTS to GSM Handover 85 

8.2.2.1 MSG-A/ MGW-A 85 

8.2.2.1.1 Bearer establishment between MGW-A and MGW-B 85 

8.2.2. 1 .2 Relocation Gommand/Handover Detect 85 

8.2.2. 1 .3 Handover Gomplete 86 

8.2.2.1.4 Interworking function 86 

8.2.2.1.5 Voice Processing function 86 

8.2.2.1.6 Handling of multiple bearers (multicaU) 86 

8.2.2.1.7 Failure Handling in MSG server 86 

8.2.2.2 MSG-B/MGW-B 86 

8.2.2.2.1 MGW selection 86 

8.2.2.2.2 Bearer establishment towards BSG-B 86 

8.2.2.2.3 Bearer establishment between MGW-A and MGW-B 86 

8.2.2.2.4 Voice Processing function 86 

8.2.2.2.5 Failure Handling in MSG server 86 

8.2.2.2.6 Example 87 

8.2.2.3 Basic Inter-MSG UMTS to GSM Handover for A Interface over IP 89 

8.2.3 Subsequent Inter-MSG UMTS to GSM Handover back to the Anchor MSG 90 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 7 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

8.2.3.1 MSC-A 90 

8.2.3.1.1 Handover Request 90 

8.2.3.1.2 Handover Request Acknowledge 91 

8.2.3.1.3 Relocation Command/Handover Detect 91 

8.2.3.1.4 Handover Complete 91 

8.2.3.1.5 Interworking function 91 

8.2.3.1.6 Voice Processing function 91 

8.2.3.1 .7 Handling of multiple bearers (multicaU) 91 

8.2.3.1.8 Failure Handling in MSG server 91 

8.2.3.2 MSC-B 91 

8.2.3.2.1 Handover Complete 91 

8.2.3.2.2 Release of bearer towards MGW-A 91 

8.2.3.2.3 Handling of multiple bearers (multicaU) 92 

8.2.3.2.4 Example 92 

8.2.3.3 Subsequent Inter-MSC UMTS to GSM Handover back to the anchor MSG for A Interface over 

IP 94 

8.2.4 Subsequent Inter-MSC UMTS to GSM Handover to a third MSG 95 

8.3 GSM to UMTS 95 

8.3.1 Intra-MSC GSM to UMTS Handover 96 

8.3.1.1 Handover Required 96 

8.3.1.2 Handover Command/Relocation Detect 96 

8.3.1.3 Relocation Complete 96 

8.3.1.4 Interworking function 96 

8.3.1.5 Codec handling 96 

8.3.1.6 Voice Processing function 96 

8.3.1.7 Failure Handling in MSG server 96 

8.3.1.8 Example 96 

8.3.2 Basic Inter-MSC GSM to UMTS Handover 98 

8.3.2.1 MSC-A 99 

8.3.2.1.1 Handover Required 99 

8.3.2.1.2 Bearer establishment between MGW-A and MGW-B 99 

8.3.2.1.3 Handover Command/Handover Detect 99 

8.3.2.1.4 Handover Complete 99 

8.3.2.1.5 Interworking function 99 

8.3.2.1.6 Codec handUng 99 

8.3.2.1.7 Voice Processing function 99 

8.3.2.1.8 Failure Handling in MSG server 100 

8.3.2.2 MSC-B 100 

8.3.2.2.1 MGW selection 100 

8.3.2.2.2 Bearer establishment towards RNC-B 100 

8.3.2.2.3 Bearer establishment between MGW-A and MGW-B 100 

8.3.2.2.4 Codec handling 100 

8.3.2.2.5 Voice Processing function 100 

8.3.2.2.6 Failure Handling in MSG server 100 

8.3.2.2.7 Example 101 

8.3.3 Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSG 103 

8.3.3.1 MSC-A 103 

8.3.3.1.1 Handover Request 103 

8.3.3.1.2 Handover Command/Relocation Detect 104 

8.3.3.1.3 Relocation Complete 104 

8.3.3.1.4 Interworking function 104 

8.3.3.1.5 Codec handling 104 

8.3.3.1.6 Voice Processing function 104 

8.3.3.1.7 Failure Handling in MSG server 104 

8.3.3.2 MSC-B / MGW-B 104 

8.3.3.2.1 Handover Required 104 

8.3.3.2.2 Handover Complete 105 

8.3.3.2.3 Release of bearer towards MGW-A 105 

8.3.3.2.4 Example 105 

8.3.4 Subsequent Inter-MSC GSM to UMTS Handover to a third MSG 107 

8.3.5 GSM to UMTS Handover with lu on IP 108 

8.4 GSM to GSM 109 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 8 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

8.4. 1 Intra-MSC Inter-BSS GSM to GSM Handover 109 

8.4.1.1 Handover Required 109 

8.4.1.2 Handover Request Acknowledge 110 

8.4. 1 .3 Handover Command/Handover Detect 1 10 

8.4.1.4 Handover Complete 110 

8.4.1.5 Interworking function 110 

8.4. 1 .6 Voice Processing function 1 10 

8.4.1 .7 Failure Handling in MSG server 1 10 

8.4.1.8 Example Ill 

8.4. 1 .9 Intra-MSC GSM to GSM Handover for A interface over IP 113 

8.4.2 Basic Inter-MSC GSM to GSM Handover 114 

8.4.2.1 MSC-A/MGW-A 114 

8.4.2. 1 . 1 Bearer establishment between MGW-A and MGW-B 114 

8.4.2.1.2 Handover Command/Handover Detect 114 

8.4.2.1.3 Handover Complete 115 

8.4.2.1.4 Interworking function 115 

8.4.2. 1 .5 Voice Processing function 1 15 

8.4.2. 1 .6 Failure Handling in MSG server 1 15 

8.4.2.2 MSC-B / MGW-B 115 

8.4.2.2.1 MGW selection 115 

8.4.2.2.2 Bearer establishment towards BSC-B 115 

8.4.2.2.3 Bearer establishment between MGW-A and MGW-B 115 

8.4.2.2.4 Voice Processing function 115 

8.4.2.2.5 Failure Handling in MSG server 1 15 

8.4.2.2.6 Example 115 

8.4.2.3 Basic Inter-MSC GSM to GSM Handover for A Interface over IP 118 

8.4.3 Subsequent Inter-MSC GSM to GSM Handover back to the Anchor MSG 1 19 

8.4.3.1 MSC-A/MGW-A 119 

8.4.3.1.1 Handover Request Acknowledge 119 

8.4.3.1 .2 Handover Command/Handover Detect 120 

8.4.3.1.3 Handover Complete 120 

8.4.3.1.4 Interworking function 120 

8.4.3.1.5 Voice Processing function 120 

8.4.3.1.6 Failure Handling in MSG server 120 

8.4.3.2 MSC-B/MGW-B 120 

8.4.3.2.1 Handover Complete 120 

8.4.3.2.2 Release of bearer towards MGW-A 120 

8.4.3.2.3 Example 120 

8.4.3.3 Subsequent Inter-MSC GSM to GSM Handover back to the anchor MSG for A Interface over IP ... 124 

8.4.4 Subsequent GSM to GSM Handover to a third MSG 124 

8.4.5 BSS Internal Handover 125 

8.4.5.1 Introduction 125 

8.4.5.2 Internal Handover Required 125 

8.4.5.3 Internal Handover Command/Handover Detect 125 

8.4.5.4 Handover Complete 125 

8.4.5.5 Interworking function 125 

8.4.5.6 Voice Processing function 125 

8.4.5.7 Failure Handling in MSG server 125 

8.4.5.8 Example for a successful BSS Internal Handover 126 

8.5 HandUng of GSM Services after UMTS to GSM Handover 128 

9 Compatibility Issues 1 28 

9.1 Interworking with GERAN (A i/f) 128 

9.1.1 Introduction 128 

9. 1 .2 A interface over TDM 129 

10 General (G)MSC server-MGW Procedures 129 

10.1 MGW Unavailable 129 

10.2 MGW Available 130 

10.3 MGW Recovery 132 

10.4 (G)MSC server Recovery 133 

10.4.1 General 133 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



9 



ETSI TS 123 205 V9.2.0 (2011-04) 



10.4.2 (G)MSC Server Restoration 133 

10.5 MGW Re-register 133 

10.6 MGW Re-registration Ordered by (G)MSC server 134 

10.7 Removal from Service of a Physical Termination 134 

10.8 Restoration to Service of a Physical Termination 135 

10.9 Audit of MGW 135 

10.9.1 Audit of Value 135 

10.9.2 Audit of Capability 136 

10. 10 MGW CapabiUty Change 136 

10.11 Void 137 

10. 12 (G)MSC Server Out of service 137 

10.13 MGW Resource Congestion Handling - Activate 137 

10. 14 MGW Resource Congestion Handling -Indication 137 

10. 15 Control association monitoring 138 

10. 16 Hanging termination detection 138 

11 Identities 139 

11.1 Bearer Address and Binding Reference 139 

11.2 MGW-Id 139 

11.3 (G)MSC server Address 139 

12 Operational Aspects 139 

12.1 Charging 139 

13 Interactions with Other Services 139 

13.1 Enhanced Multi-Level Precedence and Pre-emption service (eMLPP) 140 

13.2 CaU Deflection Service 140 

13.2.1 MGW selection and incoming side bearer establishment 140 

13.2.2 lU/A-interface release 140 

1 3 .2.3 Notification to tiie Calling Subscriber 140 

1 3 .2.4 Initial addressing 140 

13.2.5 Establishment of bearer towards the forwarded-to subscriber 140 

1 3 .2.6 Failure handling in MSC server 140 

13.2.7 Example 140 

13.3 Line identification Services 142 

13.3.1 Calling Line Identification Presentation (CLIP) 142 

13.3.2 Calling Line Identification Resti-iction (CLIR) 142 

13.3.3 Connected Line Identification Presentation (COLP) 142 

1 3 . 3 .4 Connected Line Identification Resti-iction (COLR) 1 42 

13.4 Call Forwarding Services 142 

1 3 .4. 1 Call Forwarding Unconditional (CFU) 142 

1 3 .4. 1 . 1 MGW selection 142 

13.4.1.2 Incoming side bearer establishment 142 

13.4.1.3 Notification to the Calling Subscriber 142 

1 3 .4. 1 .4 Initial addressing 142 

13.4.1.5 Establishment of bearer towards the forwarded-to subscriber 143 

1 3 .4. 1 .6 Confirmation of bearer establishment 143 

13.4.1.7 Failure handUng in GMSC server 143 

13.4.1.8 Example 143 

13.4.2 Call Forwarding on mobile subscriber Busy (CFB) 144 

13.4.2.1 Network Determined User Busy (NDUB) 144 

1 3 .4.2. 1 . 1 MGW selection 144 

1 3 .4.2. 1 .2 Incoming side bearer establishment 144 

13.4.2.1.3 Notification to the calling subscriber 144 

1 3 .4.2. 1 .4 Initial addressing 145 

13.4.2.1.5 EstabUshment of bearer towards the forwarded-to subscriber 145 

13.4.2.1.5 Confirmation of bearer establishment 145 

13.4.2. 1 .6 Failure handhng in MSC server 145 

13.4.2.1.7 Example 145 

13.4.2.2 User Determined User Busy (UDUB) 146 

13.4.2.2.1 MGW selection 146 

13.4.2.2.2 Incoming side bearer establishment 147 

13.4.2.2.3 lU/A-interface release 147 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



10 



ETSI TS 123 205 V9.2.0 (2011-04) 



131.422 A Notification to the Calling Subscriber 147 

13.4.2.2.5 Initial addressing 147 

13A22.6 Establishment of bearer towards the forwarded-to subscriber 147 

1 3 .4.2.2.7 Confirmation of bearer establishment 147 

13.4.2.2.8 Failure handling in MSC server 148 

13.4.2.2.9 Example 148 

1 3 .4.3 Call Forwarding on No Reply (CFNRy) 149 

13.4.3.1 MGW selection and incoming side bearer establishment 149 

13.4.3.2 lU/A-interface release 149 

13.4.3.3 Notification to the Calhng Subscriber 149 

13.4.3.4 Initial addressing 150 

13.4.3.5 Establishment of bearer towards the forwarded-to subscriber 150 

13.4.3.6 Failure handling in MSC server 150 

13.4.3.7 Example 150 

13.4.4 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 151 

13.4.4.1 Rerouting by HLR 151 

13.4.4.2 Rerouting by VLR 151 

13.4.4.2.1 MGW selection 152 

13.4.4.2.2 Incoming side bearer establishment 152 

13.4.4.2.3 Notification to the calling subscriber 152 

13.4.4.2.4 Initial addressing 152 

13.4.4.2.5 EstabUshment of bearer towards the forwarded-to subscriber 152 

13.4.4.2.6 Confirmation of bearer establishment 153 

13.4.4.2.7 Failure handling in MSC server 153 

13.4.4.2.8 Example 153 

13.5 Call Waiting (CW) 154 

13.5.1 Call Confirmation of the waiting call 156 

13.5.2 Acceptance of the Waiting Call 157 

13.6 CaUHold(CH) 157 

13.6.1 Hold request 157 

13.6.2 Retrieval request 158 

13.6.3 Setting up another call 158 

13.6.4 Alternate from one call to the other 158 

13.6.5 Disconnect 158 

13.6.6 Failure handling in MSC server 158 

13.6.7 Example 1 158 

13.6.8 Example 2 161 

13.7 Multiparty (MPTY) 164 

13.7.1 Beginning the Multi Party call 164 

13.7.2 Managing an active Multi Party call 164 

13.7.3 Disconnect 165 

13.7.4 Failure handling in MSC server 165 

13.7.5 Example 1 - Multiparty call establishment 165 

1 3 .7 .6 Example 2 - Private call establishment during multiparty call 168 

13.8 Closed User Group (CUG) 169 

13.9 Advice of Charge (AoC) 169 

13.10 User-to-User Signalling (UUS) 169 

13.11 Call Barring Services 169 

13.11.1 Barring of outgoing calls 169 

13.11.2 Barring of incoming calls 169 

13. 12 Explicit Call Transfer (ECT) 169 

13.12.1 Connection of remote parties 169 

13.12.2 lU/A-interface release 169 

13. 12.3 Failure handling in MSC server 169 

13.12.4 Example 170 

13.13 Completion of Calls to Busy Subscriber (CCBS) 172 

13.13.1 Clearing when tones/announcements are provided to the calling subscriber 172 

13.13.2 Network initiated mobile originated call 172 

1 3 . 1 3 .2. 1 Early Traffic Channel Assignment 173 

13.13.2.1.1 Example 173 

13.13.3 CCBS Information conveyed by Call SignalUng 174 

13.14 Multiple Subscriber Profile (MSP) 174 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 1 1 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

13.15 Multicall 174 

13.15.1 Mobile Originating 1 74 

13.15.2 Mobile Terminating 174 

13. 16 Calling Name Presentation (CNAP) 174 

13.17 Alternate Speech/Fax 1 74 

13.18 Modification of the Access Bearer 175 

13.18.1 Modification of Bearer Characteristics 175 

13.18.1.1 lumode 175 

13.18.1.2 A/Gbmode 175 

13. 18.2 IWF Protocol Change 175 

13.19 GSM Fax 175 

13.20 Voice group call service (VGCS), Voice broadcast service (VBS) 176 

1 3 .20. 1 Beginning the Voice group call 1 76 

13.20.2 Talker change in Voice group call (1 channel model) 176 

13.20.3 Disconnect 177 

1 3 .20.4 Failure handling in MSG server 177 

13.20.5 Example 177 

14 Interactions with Other Network Features and Services 181 

14.1 Customised Applications for Mobile network Enhanced Logic (CAMEL) 181 

14.1.1 Play Announcement/Send Tone 182 

14.1.1.1 Example of playing announcement by the gsmSRF 1 82 

14. 1 .2 User Interaction 1 82 

14. 1 .2. 1 Play announcement 1 82 

14.1.2.2 Detect DTMF tones 183 

14. 1.2.3 Report DTMF tones 183 

14. 1 .2.4 Cancel prompt and collect user information 1 83 

14.1.3 Call Party Handling (GPH) 183 

14.1.3.1 Call Party Handling concepts 184 

14.1.3.2 Initiate Call Attempt procedure 184 

14.1.3.2.1 Example 184 

14.1.3.3 Move Leg procedure 185 

14.1.3.4 Split Leg procedure 186 

14.1.3.5 CAMEL User interaction procedure 1 87 

14.1.3.6 Failure handling in the MSC-S 188 

14.2 1ST 188 

14.3 Operator Determined Barring (ODB) 188 

14.3.1 Barring of Outgoing Calls 188 

14.3.2 Barring of Incoming Calls 188 

14.4 DTMF 189 

14.4. 1 DTMF Tone Generation 1 89 

14.4.1.1 Inband DTMF Tone Generation 189 

14.4.1.1.1 Start DTMF 189 

14.4.1.1.2 Stop DTMF 189 

14.4.1.1.3 Example 189 

14.4.1 .2 Out-of-Band DTMF Tone Generation 190 

14.4.1.2.1 Start DTMF 190 

14.4.1.2.2 Stop DTMF 190 

14.4.1.2.3 Example 190 

14.4.2 DTMF Detection 191 

14.4.2. 1 Inband DTMF Detection 191 

14.4.2.2 Out-of-Band DTMF Detection 192 

14.5 OR 192 

14.5. 1 Optimal routeing for basic mobile-to-mobile calls 192 

14.5.2 Optimal routeing for conditional call forwarding; Early call forwarding 192 

14.5.3 Optimal routeing for conditional call forwarding; Late call forwarding 192 

14.5.3.1 MSG server 192 

14.5.3.1.1 Resume Call Handling and clearing of connection to GMSG server 192 

14.5.3.1.2 lU release 192 

14.5.3.2 GMSG server 193 

14.5.3.2. 1 Resume Call Handling and Clearing of Coimection to visited MSG server 193 

14.5.3.2.2 MGW selection 193 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 1 2 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

14.5.3.2.3 Incoming side bearer establishment 193 

14.5.3.2.4 Notification to the Calling Subscriber 193 

14.5.3.2.5 Establishment of call and bearer towards the forwarded-to subscriber 193 

14.5.3.2.6 Example 193 

14.6 Providing tones or announcements 197 

14.6.1 Preconditions when providing in-band information to the calling subscriber 197 

14.6.2 Preconditions when providing in-band information to the called subscriber 197 

14.6.3 Preconditions when providing in-band information to multiple subscribers 197 

14.6.4 Request to play an announcement/tone 197 

14.6.5 Stopping an announcement/tone 197 

14.6.6 Announcement/tone completed 198 

14.6.7 Example 1 198 

14.6.8 Example 2 199 

14.7 Global Text Telephony 200 

14.8 Emergency Calls 201 

14.9 Subscriber and equipment trace 201 

14.10 Customized Alerting Tone 20 1 

14.10.1 General 201 

14.10.2 Audio CAT 201 

14. 10.2. 1 Audio CAT Activated by the Calling Party 201 

14. 10.2.2 Audio CAT Activated by the Called Party 202 

14.10.3 Multimedia CAT 202 

14.10.3.1 Introduction 202 

14. 10.3.2 Multimedia CAT Activated by the Calling Party 202 

14.10.3.3 Multimedia CAT Activated by the Called Party 203 

14.10.3.3.1 Mobile originated multimedia call 203 

14.10.3.3.2 Mobile terminated multimedia call 203 

14.10.3.3.3 Example 203 

15 Tunnelling 205 

15.1 Forward Bearer Establishment 205 

15.1.1 Outgoing Side 205 

15.1.1.1 Tunnel Selection 205 

15.1.1.2 Initial addressing 205 

15.1.1.3 Fast forward tunnelling 205 

15.1.1.4 Delayed forward tunnelling 206 

15.1.1.5 Bearer control signalling transfer 206 

15.1.2 Incoming Side 206 

15.1.2.1 Initial addressing 206 

15.1.2.2 Tunnel Selection 206 

15.1.2.3 Fast forward tunnelling 206 

15. 1.2.4 Delayed forward tunnelling 207 

15.1.2.5 Bearer control signalling transfer 207 

15.1.2.6 Example 207 

15.2 Backward Bearer Establishment 208 

15.2.1 Outgoing Side 208 

15.2.1.1 Tunnel Selection 208 

15.2.1.2 Initial addressing 209 

15.2.1.3 Fast forward tunnelling 209 

15.2.1.4 Delayed backward tunnelling 209 

15.2.1.5 Bearer control signalling transfer 209 

15.2.2 Incoming Side 209 

15.2.2.1 Initial addressing 209 

15.2.2.2 Tunnel Selection 209 

15.2.2.3 Fast forward tunnelling 209 

15.2.2.4 Delayed backward tunnelling 210 

15.2.2.5 Bearer control signalling transfer 210 

15.2.2.6 Example 210 

16 Messages/Procedures and their contents 212 

16.1 Messages between (G)MSC servers 213 

16.2 Procedures between (G)MSC server and MGW 215 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



13 



ETSI TS 123 205 V9.2.0 (2011-04) 



16.2.1 Change Flow Direction 215 

16.2.2 Join Bearer Termination 216 

16.2.3 Isolate Bearer Temiination 216 

16.2.4 Establish Bearer 217 

16.2.5 Prepare Bearer 219 

16.2.6 Reserve Circuit 221 

16.2.7 Change Through-Connection 222 

16.2.8 Activate Interworking Function 222 

16.2.9 Release Bearer 223 

16.2. 10 Bearer Established 223 

16.2.1 1 Bearer Released 224 

16.2.12 Release Termination 224 

16.2.13 Tunnel Information Up 225 

16.2.14 Tunnel Information Down 225 

16.2.15 Send Tone 226 

16.2.16 Stop Tone 226 

16.2.17 Play Announcement 227 

16.2.18 Stop Announcement 227 

16.2.19 Announcement Completed 228 

16.2.20 Tone Completed 228 

16.2.21 Detect DTMF 229 

16.2.22 Stop DTMF Detection 229 

16.2.23 Report DTMF 230 

16.2.24 Send DTMF 230 

16.2.25 Stop DTMF 231 

16.2.26 MOW Out-of-Service/ Maintenance locking 23 1 

16.2.27 MOW Communication Up 232 

16.2.28 MOW Restoration 232 

16.2.29 MOW Register 233 

16.2.30 MGW Re-register 234 

16.2.3 1 (G)MSC Server Ordered Re-register 234 

16.2.32 (G)MSC Server Restoration 235 

16.2.33 (G)MSC Server Out of Service 235 

16.2.34 Termination Out-of-Service 236 

16.2.35 Termination Restoration 236 

16.2.36 Audit Value 237 

16.2.37 Audit Capability 237 

16.2.38 Capability Update 238 

16.2.39 Command Reject 238 

16.2.40 Activate Voice Processing Function 239 

16.2.41 Modify Bearer Characteristics 240 

16.2.42 Protocol Negotiation Resuh 241 

16.2.43 MGW Resource Congestion HandUng - Activate 241 

16.2.44 MGW Resource Congestion HandUng - Indication 242 

16.2.45 Bearer Modification Support 242 

16.2.46 CTM report 243 

16.2.47 Prepare_IP_Transport 244 

16.2.48 Modify IP Transport Address 245 

16.2.49 Emergency Call Indication 245 

16.2.50 Trace Activation 246 

16.2.51 Trace Deactivation 246 

16.2.52 Trace Activation result notification 247 

16.2.53 Continuity Check Tone 247 

16.2.54 Continuity Check Verify 247 

16.2.55 Continuity Check Response 248 

16.2.56 Rate Change 248 

16.2.57 Bearer Modifed 249 

16.2.58 Bearer Modification Failed 249 

16.2.59 Termination heartbeat indication 250 

16.2.60 Inactivity timeout activation 250 

16.2.61 Inactivity timeout indication 25 1 

16.2.62 Reserve RTP Connection Point 25 1 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 1 4 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

16.2.63 Configure RTP Connection Point 254 

16.2.64 Reserve and Configure RTP Connection Point 257 

16.2.65 Realm Availability Change - Activation 259 

16.2.66 Realm Availability Change - Indication 260 

17 Bearer Redirect 260 

17.1 Example of use of Bearer Redirect with Call Forwarding on No Reply (CFNRy) 260 

1 8 (G)MSC MGW Tandeming 263 

18.1 Example of use of MSG MGW Tandeming during call setup to provide bearer access to specialised 

MGW resources 263 

19 Timers for bearer independent CS core network 264 

20 Multiple IP Realms 264 

Annex A (informative): Cliange History 266 

History 269 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



15 



ETSI TS 123 205 V9.2.0 (2011-04) 



Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the stage 2 description for the bearer independent CS core network. The stage 2 shall 
cover the information flow between the GMSC server, MSG server and media gateways. Note that nothing in the 
present document shall preclude an implementation of a combined MSG Server and MGW. The present document shall 
show the GS core network termination of the lu interface in order to cover the information flow stimulus to the core 
network and describe the interaction with the supplementary and value added services and capabilities. 

For the purposes of the present document, the protocol used over the Nc interface is an enhanced call control protocol 
supporting call bearer separation such as BIGG (which is specified in [22]). The protocol used over the Mc interface is 
H.248 (which is specified in 3GPP TS 29.232 [6]). Existing specifications and recommendations shall not be repeated, 
as such the relevant specification shall be referred to. 

SIP-I based GS core network is further specified in 3GPP TS 23.231 [42]. 

The present document is applicable only for ATM or IP transport in the GS core network. 




- Signalling 

Interface 
" Signalling and Data Transfer 

Interface 



Figure 1 : CS core network logical architecture 

The GAP interfaces and the interfaces towards the HLR are outside the scope of the present document. 

Details of Transcoder-Free Operation are outside the scope of the present document. Please see 3GPPTS 23.153 [3] for 
more information. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[ 1 ] 3GPP TR 2 1 .905 : " Vocabulai-y for 3GPP Specifications" . 

[2] 3GPP TS 23.002: "Network architecture". 
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3 Symbols and abbreviations 

3.1 Symbols 

For the purposes of the present document, the following symbols apply: 

lu Interface between the RNS and the core network. It is also considered as a reference point. 

Mc Interface between the server and the media gateway. 

Nb Interface between media gateways. 

Nc The NNI call control interface between (G)MSC servers. 



3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



BCF 


Bearer Control Function 


BICC 


Bearer Independent Call Control 


CIC 


Call Instance Code 


CCF 


Call Control Function 


CS 


Circuit Switched 


GERAN 


GSM/EDGE Radio Access Network 


lAM 


Initial Address Message 


IETF 


Internet Engineering Task Force 


IP 


Internet Protocol 


IPv4 


Internet Protocol version 4 


IPv6 


Internet Protocol version 6 


MGW 


Media GateWay 


MGC 


Media Gateway Controller 


MSC-S 


MSC Server 


MTP2 


Message Transfer Part layer 2 


MTP3 


Message Transfer Part layer 3 
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NNI 


Network-Network interface 


RAB 


Radio Access Bearer 


RANAP 


Radio Access Network Application Protocol 


SBSS 


Serving Base Station System 


SRNS 


Serving Radio Network Subsystem 


TCAP 


Transaction Capabilities Application Part 


TFO 


Tandem Free Operation 


TRAU 


Transcoder and Rate Adapter Unit 


TrFO 


Transcoder Free Operation 


UDP 


User Datagram Protocol 


UTRAN 


UMTS Terrestrial Radio Access Network 



3.3 Definitions 

UE : User equipment. This specification makes no distinction between MS (mobile station) and UE. 

A/Gb mode: mode of operation of the UE when connected to the Core Network via GERAN and the A and/or Gb 
interfaces. Throughout this specification the term GSM refers to GERAN A/Gb mode. 

lu mode: mode of operation of the UE when connected to the Core Network via GERAN or UTRAN and the lu 
interface. Throughout this specification the term UMTS refers to UTRAN or GERAN lu mode. 



4 IVIain Concepts 

4.1 General 

The circuit switched core network enables the support of different transports (e.g. ATM or IP) in a bearer-independent 
fashion. For the ATM and IP transport, there is a strict separation between the call control level and the bearer control 
level. In the case of ATM or IP transport, the passage of compressed speech at variable bit rates is possible through the 
CS core network. 

The CS core network shall employ the MSC server, GMSC server and media gateways. The GMSC server and MSC 
server shall provide the call control and mobility management functions, and the media gateway shall provide the bearer 
control and transmission resource functions. The media gateway shall contain the stream manipulating functions. 

The GMSC server and MSC servers are connected to the media gateway via the Mc reference point. The MSC servers 
and GMSC servers are connected with the Nc reference point. There may be a number of call control transit nodes 
between the MSC server and GMSC server in the Nc reference point. The MGWs are connected with the Nb reference 
point. 

The users connected to the CS core network shall not be aware whether a MSC server - media gateway combination is 
used, or a monolithic MSC is used. 

4.2 Bearer-Independent Call Control 

The protocol used on the Nc interface shall be a call control protocol supporting IP and ATM transports in a 
bearer-independent manner for the ISDN service set, allowing the physical separation of the call control entities from 
the bearer control entities. 

An exception to this bearer independence concept is if lu interface is on IP and the IP addresses are to be exchanged via 
call control plane signalling (known by the MSC due to configuration data). In this case the specific handUng is 
described separately. 

Another exception to the bearer independence concept is the case of A interface user plane over IP (AoIP). In that case 
the IP addresses/UDP port numbers are to be exchanged via call control plane signalling. Specific handling is also 
described separately for this case. 
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4.3 H.248/MEGACO 

H.248/MEGACO has been jointly developed within the ITU-T and the IETF, and supports a separation of call control 
entities from bearer control entities, and a separation of bearer control entities from transport entities. H.248 is used on 
the Mc interface between the (G)MSC servers and the media gateway. 



5 General Circuit Switched Core Network Domain 
Architecture 

5.1 Logical Architecture 

The overall CS core network logical architectiu'e is shown in figure 1 . 

5.1 .1 CS Core Network Nodes 

5.1.1.1 MSG Server 

The MSG server mainly comprises the call control and mobility control parts of a GSM/UMTS MSG as described in 
3GPP TS 23.002 [2]. It is also integrated with a VLR to hold the mobile subscriber's service data and GAMEL related 
data. 

The MSG server terminates the user-network signalling (see 3GPP TS 24.008 [4]) and translates it into the signalling 
over the Nc interface. The MSG Server terminates the lu control plane signalling and its transport bearer 
(see 3GPP TS 25.413 [26] and 3GPP TS 25.412 [30]). It also terminates the signalling over the Mc interface with the 
Media Gateway. 

The MSG server controls the parts of the call state model that pertain to connection control for media channels in an 
MGW. It also contains the "Gall Gontrol Function" in the BIGG model. 

5.1.1.2 GMSC Server 

The GMSG server mainly comprises the call control and mobility control parts of a GSM/UMTS GMSG as described in 

3GPP TS 23.002 [2]. 

The GMSG server terminates the signalling over the Nc interface and the call control interfaces to the external 
networks. It also terminates the signalUng over the Mc interface towards the Media Gateway. 

The GMSG server controls the parts of the call state model that pertain to connection control for media channels in an 
MGW. It also contains the "Gall Gontrol Function" in the BIGG model. 

5.1.1.3 Media Gateway 

The Media Gateway terminates the signalling over the Mc interface from the (G)MSG servers. The Media Gateway 
terminates the lu transport network control plane signalling with its transport bearer (see 3GPP TS 25.410 [31] and 
3GPP TS 25.414 [32]). The Media Gateway also terminates the lu user plane protocol (see 3GPP TS 25.415 [20]). It 
also terminates the bearer control signalling and the transport bearer over the Nb interface (see 3GPP TS 29.414 [21] 
and 3GPPTS 29.415 [7]). 

The Media Gateway contains bearer terminations and media manipulation equipment (e.g. transcoders, echo cancellers, 
or tone senders). It may perform media conversion and framing protocol conversion. 
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5.1 .2 CS Core Network Interfaces and Reference Points 



5.1.2.1 Mc Interface 

The Mc reference point in the present document considers the aspects of the interface between the (G)MSC server and 
the MGW. The H.248 protocol [5] together with 3GPP specific extensions/packages shall be used over the Mc 
interface. 

5.1.2.2 Nc Interface 

The Network-Network based call control is used over the Nc interface. Any suitable call control protocol may be used 
over the Nc interface (e.g. BICC). 

5.1.2.3 Nb Interface 

The bearer control signalling and transport are carried over the Nb interface. 

5.2 Network Interworking 

5.2.1 Interworking on tine Nc Reference Point 

Interworking between the Nc reference point, call control protocols and ISUP is defined within the 3GPP stage 3 
documentation for each protocol (or by references specified in stage 3 documentation [6]). 

5.2.2 Interworking on the Nb Reference Point 

The interworking is specified in 3GPP TS 29.415 [7] and 3GPP TS 29.414 [21]. 



6 Call Establishment 

NOTEl: All message sequence charts in this clause are examples. All valid call establishment message sequences 
can be derived from the example message sequences and associated message pre-conditions. 

NOTE2: The continuity indication in the 1AM is not used to indicate that a continuity check will be performed on 
the current leg of the call, but it is used to indicate that a Continuity message can be expected as a result 
of a continuity check on a preceding ISUP circuit, or establishment of a preceding bearer cormection. 



6.1 Basic Mobile Originating Call 
6.1 .1 Forward bearer establishment 

The mobile originating call shall be estabUshed in accordance with 3GPP TS 23.108 [17]. The following clauses 
describe the additional requirements for the bearer independent CS core network. If out-of-band transcoder control is 
applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 



6.1.1.1 MGW selection 

The MSC server shall select an MGW for the bearer connection before it performs the access bearer assignment or the 
network side bearer establishment. This may happen either before sending the 1AM or after receiving the Bearer 
Information message. In the latter case, the MGW selection may be based on a possibly received MGW-id from the 
succeeding node (bullet 1 or bullet 2 in figure 6.2). For GSM, if performing Service based handover (see 3GPP TS 
48.008 [27]) the MSC Server may omit MGW selection at this time. 
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6.1 .1 .2 Initial addressing 

The MSC server shall indicate in the lAM that forward bearer establishment is to be used. If access bearer assignment 
has not been completed, the MSC server shall indicate that the Continuity message will follow. However, if late access 
bearer assignment (assignment after alerting or answer) is used the MSC server shall not indicate that the Continuity 
message will follow. The MSC server provides the bearer characteristics to the succeeding node in the lAM. If the 
MGW is selected at an earlier stage the MGW-id may also be provided in the lAM (bullet 1 in figure 6.2). 

6.1.1.3 Network side bearer establishment 

The MSC server shall select bearer characteristics for the network side bearer connection before sending the lAM. After 
the succeeding node has provided a bearer address and a binding reference in the Bearer Information message the MSC 
server uses the Establish Bearer procedure to request the MGW to establish a bearer towards the destination MGW. The 
MSC server provides the MGW with the bearer address, the binding reference and the bearer characteristics (bullet 2 in 
figure 6.2). 

6.1 .1 .4 Access bearer assignment 

The MSC server shall select bearer characteristics for the access bearer. 

For UMTS, before the MSC server starts the access bearer assignment, the MSC server requests the MGW to prepare 
for the access bearer establishment using the Prepare Bearer procedure. The MSC server requests the MGW to provide 
a bearer address and a binding reference, provides the MGW with the bearer characteristics and requests notification 
that the bearer can be modified. For speech calls, the MSC server shall provide the MGW with the speech coding 
information and conditionally GTT related information in accordance with 3GPP TS 23.226 [28] for the bearer. For a 
non-speech call the MSC server also provides the MGW with a PLMN Bearer Capability [4]. After the MGW has 
rephed with the bearer address and the binding reference the MSC server requests access bearer assigrmient using the 
provided bearer address and binding reference (bullet 3 in figure 6.2) in accordance with 3GPP TS 25.413 [26]. The 
MSC shall only be notified by the MGW using Bearer Modification Support procedure if the existing link 
characteristics of the access bearer can be modified at a later stage, see subclause 13.18.1. 

For GERAN lu mode the MSC Server receives the GERAN capabilities within the RANAP INITIAL UE MESSAGE, 
indicating the services (e.g. for CS speech services the supported codec types and, for an adaptive codec type, the 
supported codec modes (for definition see [27])), which will be available at the RAB establishment procedure. The 
MSC server shall take the indicated GERAN capabilities into account as well as the received MS capabilities when 
negotiating a service. Additionally, when requesting the access bearer assignment the MSC server shall indicate to the 
GERAN the selected service (e.g. selected codec type). The MSC server shall not set codec information in the NAS 
Synchronisation Indicator (see [4]). Instead it shall set codec information in the GERAN BSC container. 

For GSM, before the MSC server starts the access bearer assignment, the MSC server uses the Reserve Circuit 
procedure to seize a TDM circuit. For a non-speech call the MSC server also provides the MGW with a PLMN Bearer 
Capability [4] and a GSM channel coding. After the MGW has replied to the TDM circuit seizure, the MSC server 
requests access bearer assignment (bullet 4 in figure 6.2) in accordance with 3GPP TS 48.008 [27]. If performing 
Service based handover (see 3GPP TS 48.008 [27]) the MSC Server may omit to perform Reserve Circuit procedure. 

6.1.1.5 Framing protocol initialisation 

In 3GPP CS CN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is estabUshed through the CN 
in a forward direction. This is established independently of the bearer establishment direction. The MGW derives the 
forward direction ftom information sent by the MSC server within the Establish Bearer and Prepare Bearer procedures 
[6]. 

6.1 .1 .6 Confirmation of bearer establishment 

If the lAM which was sent to the succeeding node indicated that the Continuity message will follow, the MSC server 
sends the Continuity message when the access bearer assigimient has been completed (bullet 5 in figure 6.2). 
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6.1.1.7 Through-Connection 

During any one of the Prepare Bearer, Reserve Circuit and Establish Bearer procedures, the MSC server will use the 
Change Through-Connection procedure to request the MGW to through-coimect the bearer terminations so that the 
bearer will be backward through-connected (bullet 2, and bullet 3 or 4 in figure 6.2). 

For a multimedia call, the MSC may request the MGW to both-way through-connect the bearer using the Change 
Through-Connection procedure to generate a multimedia CAT (see subclause 14.10.3.1). 

Otherwise when MSC server receives the answer indication, it requests the MGW to both-way through-coimect the 
bearer using the Change Through-Cormection procedure (bullet 6 in figure 6.2). 

6.1 .1 .8 Interworking function 

The MGW may use an interworking function that is based on the PLMN Bearer CapabiUty [4] of the bearer 
termination. The activation of the possible interworking function in both bearer terminations will be requested by the 
MSC server at reception of the answer indication using the Activate Interworking Function procedure (bullet 6 in figure 
6.2). 

6.1.1.9 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

6.1.1.10 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The MSC server shall request the activation of voice processing functions in the bearer terminations. For 
non-speech calls, the MSC server has the ability to instruct the MGW to disable the voice processing functions (bullet 6 
in figure 6.2). 

6.1 .1 .1 1 Failure handling in MSC server 

If any procedure between the MSC server and the MGW has not completed successfully or the MSC server receives a 
Bearer Released procedure from the MGW, the call shall be cleared as described in clause 7.3, (G)MSC server initiated 
call clearing or in clause 7.4, MGW initiated call clearing. Alternatively, the MSC server may only release the resources 
in the MGW that caused the failure, possibly select a new MGW for the bearer connection and continue the call 
establishment using new resources in the selected MGW. 

6.1.1.12 Example 

Figure 6.1 shows the network model for the mobile originating call. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A-interface) 
and the bearer. The MSC server seizes one context with two bearer terminations in the MGW. The bearer termination 
Tl is used for the bearer towards the RNC/BSC and the bearer termination T2 is used for the bearer towards the 
succeeding MGW. 
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Figure 6.1 : Basic IVIobile Originating Call, Forward Bearer Establishment (network model) 

Figure 6.2 shows the message sequence chart example for the mobile originating call. In the example the MSC server 
requests seizure of the network side bearer termination and establishment of the bearer when the Bearer Information 
message is received from the succeeding node. After the network side bearer termination is seized the MSC server 
requests seizure of the access side bearer termination. When the MSC server receives an answer indication, it shall 
requests the MGW to both-way through-connect the bearer terminations. The MSC shall also request the possible 
activation of the interworking function in both terminations and the possible activation of the voice processing functions 
for the bearer terminations. 
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Figure 6.2/1 : Basic lUlobile Originating Call, Forward Bearer Establishment 

(message sequence chart) 
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Figure 6.2/2: Basic Mobile Originating Call, Forward Bearer Establisliment 
(message sequence chart continue) 

6.1 .2 Backward bearer establishment 

The basic mobile originating call shall be established in accordance with 3GPP TS 23.108 [17]. The following clauses 
describe the additional requirements for the bearer independent CS core network. If out-of-band transcoder control is 
applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 



6.1.2.1 



MGW selection 



The MSC server shall select an MGW for the bearer connection before it performs the access bearer assignment or the 
network side bearer establishment. This happens before sending the lAM (bullet 1 or 2 in figure 6.4). For GSM, if 
performing Service based handover (see 3GPP TS 48.008 [27]) the MSC Server may omit MGW selection at this time. 



6.1.2.2 



Network side bearer establishment 



The MSC server shall select bearer characteristics for the network side bearer connection before sending the lAM. The 
MSC server requests the MGW to prepare for the network side bearer establishment using the Prepare Bearer 
procedure. The MSC server requests the MGW to provide a bearer address and a binding reference, and provides the 
MGW with the bearer characteristics (bullet 3 in figure 6.4). After the MGW has replied with the bearer address and the 
binding reference, the MSC server sends the LAM to the succeeding node. 



6.1.2.3 



Initial addressing 



The MSC server shall indicate in the lAM that backward bearer establishment is to be used. If access bearer assignment 
has not been completed, the MSC server shall indicate that the Continuity message will follow. However, if late access 
bearer assigimient (assigimient after alerting or answer) is used the MSC server shall not indicate that the Continuity 
message will follow. The MSC server provides the bearer characteristics, the bearer address and the binding reference 
to the succeeding node in the lAM. The MSC server may also provide the MGW-id in the 1AM (bullet 4 in figure 6.4). 
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6.1 .2.4 Access bearer assignment 

The MSG server shall select bearer characteristics for the access bearer. 

For UMTS, before the MSG server starts the access bearer assignment, the MSG server requests the MOW to prepare 
for the access bearer establishment using the Prepare Bearer procedure. The MSG server requests the MOW to provide 
a bearer address and a binding reference, provides the MOW with the bearer characteristics and requests notification 
that the bearer can be modified. For speech calls, the MSG server shall provide the MOW with the speech coding 
information and conditionally GTT related information in accordance with 3GPP TS 23.226 [28] for the bearer. For a 
non-speech call the MSG server also provides the MGW with a PLMN Bearer Gapability [4]. After the MGW has 
rephed with the bearer address and the binding reference the MSG server requests access bearer assignment using the 
provided bearer address and binding reference (bullet 1 in figure 6.4) in accordance with 3GPP TS 25.413 [26]. The 
MSG shall only be notified by the MGW using the Bearer Modification Support procedure if the existing link 
characteristics of the access bearer can be modified at a later stage, see subclause 13.18.1. 

For GERAN lu mode the MSG Server receives the GERAN capabihties within the RANAP INITIAL UE MESSAGE, 
indicating the services (e.g. for GS speech services the supported codec types and, for an adaptive codec type, the 
supported codec modes (for definition see [27])), which will be available at the RAB establishment procedure. The 
MSG server shall take the indicated GERAN capabilities into account as well as the received MS capabilities when 
negotiating a service. Additionally, when requesting the access bearer assignment the MSG server shall indicate to the 
GERAN the selected service (e.g. selected codec type). The MSG server shall not set codec information in the NAS 
Synchronisation Indicator (see [4]). Instead it shall set codec information in the GERAN BSG container. 

For GSM, before the MSG server starts the access bearer assignment, the MSG server uses the Reserve Gircuit 
procedure to seize a TDM circuit. For a non-speech call the MSG server also provides the MGW with a PLMN Bearer 
Gapabihty [4] and a GSM channel coding. After the MGW has replied the TDM circuit seizure the MSG server requests 
access bearer assignment (bullet 2 in figure 6.4) in accordance with 3GPP TS 48.008 [27]. If performing Service based 
handover (see 3GPP TS 48.008 [27]) the MSG Server may omit to perform Reserve Gircuit procedure. 

6.1 .2.5 Framing protocol initialisation 

In 3GPP GS GN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is established through the GN 
in a forward direction. This is estabhshed independently of the bearer estabhshment direction. The MGW derives the 
forward direction from information sent by the MSG server within the Establish Bearer and Prepare Bearer procedures 
[6]. 

6.1 .2.6 Confirmation of bearer establishment 

If the lAM was sent to the succeeding node indicating that the Gontinuity message will follow, the MSG server sends 
the Gontinuity message when the access bearer assignment has been completed. 

6.1.2.7 Through-Connection 

During the Prepare Bearer or Reserve Gircuit procedures, the MSG server will use the Ghange Through-Gonnection 
procedure to request the MGW to through-connect the bearer terminations so that the bearer will be backward 
through-connected (bullet 1 or 2, and bullet 3 in figure 6.4). 

For a multimedia call, the MSG may request the MGW to both- way through-connect the bearer using the Ghange 
Through-Gonnection procedure to generate a multimedia GAT (see subclause 14.10.1). 

Otherwise when the MSG server receives the answer indication, it requests the MGW to both-way through-connect the 
bearer using the Ghange Through-Gonnection procedure (bullet 5 in figure 6.4). 

6.1 .2.8 Interworking function 

The MGW may use an interworking function that is based on the PLMN Bearer Gapabihty [4] of the bearer 
termination. The activation of the possible interworking fiinction in both bearer terminations will be requested by the 
MSG server at reception of the answer indication using the Activate Interworking Function procedure (bullet 5 in 
figure 6.4). 
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6.1.2.9 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

6.1 .2.1 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The MSG server shall request the activation of the voice processing functions in the bearer terminations. 
For non-speech calls, the MSG server has the ability to instruct the MGW to disable the voice processing functions 
(bullet 5 in figure 6.4). 

6.1 .2.1 1 Failure handling in MSG server 

If any procedure between the MSG server and the MGW has not completed successfully or the MSG server receives a 
Bearer Released procedure from the MGW, the call shall be cleared as described in clause 7.3, (G)MSG server initiated 
call clearing or in clause 7.4, MGW initiated call clearing. Alternatively, the MSG server may only release the resources 
in the MGW that caused the failure, possibly select a new MGW for the bearer connection and continue the call 
establishment using new resources in the selected MGW. 

6.1.2.12 Example 

Figure 6.3 shows the network model for the mobile originating call. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A-interface) 
and the bearer. The MSG server seizes one context with two bearer terminations in the MGW. The bearer termination 
Tl is used for the bearer towards the RNC/BSG and the bearer termination T2 is used for the bearer towards the 
succeeding MGW. 



r ^ 




Figure 6.3: Basic IVIobile Originating Call, Backward Bearer Establishment 

(network model) 

Figure 6.4 shows the message sequence chart example for the mobile originating call. In the example the MSG server 
requests seizure of the access side bearer termination and network side bearer termination. As the access bearer 
assignment has been completed before the lAM, no Gontinuity message will be sent. When the MSG server receives an 
answer indication, it requests the MGW to both-way through-connect the bearer terminations. The MSG server, shall 
also request the possible activation of the interworking function in both bearer terminations. The MSG server shall 
request the possible activation of the voice processing functions for the bearer terminations. 
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Figure 6.4/1 : Basic IVIobile Originating Call, Backward Bearer Establishment 

(message sequence chart) 
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Figure 6.4/2: Basic lUlobile Originating Call, Backward Bearer Establishment 
(message sequence chart continue) 

6.1 .3 Originating Call Establishment For lu Interface on IP 

If luCS on IP is supported by the MSC server, the Core Network side procedures described in 6. 1 . 1 or 6. 1 .2 shall apply. 
For the access side termination, the exchange of IP addresses via call control procedures is described in this clause. 

Before the MSC server starts the access bearer assignment, the MSC server requests the MGW to prepare for the access 
bearer using the Prepare_IP_Transport procedure. The MSC server requests the MGW to provide an IP Transport 
Address and a lu UDP Port and provides the MGW with the bearer characteristics. For speech calls, the MSC server 
shall provide the MGW with the speech coding information and conditionally GTT related information in accordance 
with 3GPP TS 23.226 [28]. For a non-speech call the MSC server also provides the MGW with a PLMN Bearer 
Capability [4]. After the MGW has replied with the IP address and UDP Port the MSC server requests access bearer 
assignment using the provided IP address and UDP Port in accordance with 3GPP TS 25.413 [26J. The IP addresses and 
UDP Ports of the MGW and the RNC are exchanged via the RANAP procedures. If the bearer transport is IP and luUP 
mode is Transparent, when the MSC receives the RANAP RAB assignment response it shall send the RNC IP address 
and UDP Port to the MGW Access bearer termination using the Modify_IP_Transport_Address procedure. 

If the bearer transport is IP and luUP mode is Support, the MGW shall use the source IP address and UDP Port of the 
luUP Init packet received from the radio access network as the destination address for subsequent downlink packets. 



The sequence is shown in figure 6.1.3/1. 
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Figure 6.1 .3/1 : Call Establishment for lu on IP 

6.1 .4 Forward bearer establishment with Trace Session Activation 

The mobile originating call shall be established in accordance with 3GPP TS 23.108 [17]. The following clause describe 
the additional requirement for the bearer independent CS core network if a trace session is activated from a MSG Server 
to a MGW. 



6.1.4.1 



Trace activation 



When a Trace Session is activated in the MSG Server and the trace control and configuration parameters requires Trace 
Session activation to the MGW, the MSG Server activates the Trace Session to the MGW by using the trace activation 
procedure. 
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6.1.4.2 Example 

Figure 6.1.4.1 shows the network model for the mobile originating call. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A-interface) 
and the bearer. The MSG server seizes one context with two bearer terminations in the MGW. The bearer termination 
Tl is used for the bearer towards the RNG/BSG and the bearer termination T2 is used for the bearer towards the 
succeeding MGW. 




Figure 6.1.4.1 : Basic lUlobile Originating Call, Forward Bearer Establishment with Trace Session 

Activation (network model) 

Figure 6.1.4.2 shows the message sequence chart example for the mobile originating call. In the example the MSG 
server activates the Trace Session to MGW when it request the creation of the incoming and outgoing termination with 
ADD request. MGW sends the Trace Session Activation result with NOTIFY request to MSG Server. 
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Figure 6.1.4.2/1 : Basic IVIobile Originating Call, Forward Bearer Establishment with Trace Session 

Activation 
(message sequence chart) 
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UE 



RNC/BSC 



ALBlTIvfG 



CON'^ECT 



MSC-S 



Context (CI) 
Context (CI) 

Context (CI) 
Context (CI) 



MOW 



Address Comphte 



Answ 



MOD.request (Tl) 



MOD.reply (Tl) 



MOD.request (T2) 



310D.reply (T2) 



Change Through-Connection + 
Activate Inter- Working Function 
(when applicable) -H 
Activate Voice Processing 
Function (when appUcable) 



Activate Inter-Working 
Function (when applicable) H 
Activate Voice Processing 
Function (when applicable) 



Figure 6.1.4.2/2: Basic lUlobile Originating Call, Forward Bearer Establisliment with Trace Session 

Activation 
(message sequence chart continue) 

6.1 .5 Originating Call Establishment for A interface over IP 

If AoIP is supported by the MSC server, the Core Network side procedures described in 6.1.1 or 6.1.2 shall apply. For 
the access side termination, the exchange of IP addresses and UDP port numbers via call control procedures is described 

in this clause. 

Before the MSC server sends the Assignment Request to the BSC, the MSC server requests the MGW to reserve an 
RTP bearer termination using the Reserve RTP Connection Point procedure. The MSC server requests the MGW to 
reserve an IP Address and UDP Port and also may indicate that the IP interface type is for AoIP.The MGW reserves the 
RTP termination and indicates the IP address and UDP port number to the MSC server. MSC server then requests 
access bearer assignment using the provided IP address and UDP Port. When MSC server receives the BSSMAP 
ASSIGNMENT COMPLETE message, it shall send the BSC IP address and UDP Port to the MGW Access bearer 
termination using the Configure RTP Connection Point procedure. 



The sequence is shown in figure 6.1.5.1. 
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UE 



BSC 



SETUP 



CALL PRCiCEflDING 



MSC -S 



Context ($) 
Context (CI) 



Context (C1) 
Context (CI) 
ASSIGNMENT REQ 



ASSIGNMENT COMPL 



Context (C1 
Context(C1 1 



\DD.reply (T2) 



^DD. request ($) 











MGW 



Initial Addrdss 



Bearer Inforniatioi 



ADD. request ($) 



i\DD.reply (T1) 



MOD.request (T1) 



Mod. reply (T1) 



Continui 



Establish Bearer + 

Change Through Connection 



Bearer Establishment 



Reserve RTF Connection Point + 
Change Through Connection 



Configure RTP Connection Point 



Figure 6.1.5.1: Originating Call Establishment for AolP 



6.2 Basic Mobile Terminating Call 
6.2.1 Forward bearer establishment 

The basic mobile terminating call shall be established in accordance with 3GPP TS 23.108 [18]. The following clauses 
describe the additional requirements for the bearer independent CS core network. If out-of-band transcoder control is 
applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 



6.2.1.1 GMSC server 
6.2.1.1.1 MGW selection 

The GMSC server shall select an MGW for the bearer connection before it performs the incoming side bearer 
establishment or the outgoing side bearer establishment. This may happen either before sending the lAM or after 
receiving the Bearer Information message. If the GMSC server received an MGW-id from the preceding node and/or 
from the succeeding node, then it may use one of them for the MGW selection (bullet 1 or bullet 4 in figure 6.6). 

NOTE: As an implementation option, if there is no need for the GMSC server to manipulate the bearer, the 

GMSC server may perform call control signalling without any associated MGW. In that case the bearer 
related information shall be passed transparently through the GMSC server. 
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6.2.1 .1 .2 Initial addressing 

The GMSC server shall indicate in the lAM that forward bearer establishment is to be used. The GMSC server shall 
also indicate in the lAM that the Continuity message will follow if either of the following conditions is satisfied before 
sending the I AM: 

1 . the incoming lAM indicated that the Continuity message will follow, but no Continuity message has been 
received; 

2. the GMSC server selected an MGW, but a notification of successfiil bearer establishment on the incoming side 
has not been received from the MGW. 

The GMSC server shall provide the bearer characteristics to the succeeding node in the lAM. If the MGW is selected at 
an early stage the MGW-id may also be provided in the lAM (bullet 1 in figure 6.6). 

6.2.1 .1 .3 Outgoing side bearer establishment 

The GMSC server shall select bearer characteristics for the outgoing side bearer connection before it sends the lAM. 
After the GMSC server has received a bearer address and a binding reference in the Bearer Information message from 
the succeeding node the GMSC server requests the MGW to establish a bearer to the given destination MGW using the 
EstabUsh Bearer procedure. The GMSC server shall provide the MGW with the bearer address, the binding reference 
and the bearer characteristics (bullet 4 in figure 6.6). 

6.2.1 .1 .4 Incoming side bearer establishment 

The GMSC server requests the MGW to prepare for the incoming side bearer establishment using the Prepare Bearer 
procedure. The GMSC server requests the MGW to provide a bearer address, a binding reference and to notify when the 
bearer is established (bullet 5 in figure 6.6). The GMSC server also provides the MGW with the bearer characteristics 
that was received from the preceding node in the lAM. After the MGW has replied with the bearer address and the 
binding reference, the GMSC server sends the Bearer Information message to the preceding node. The GMSC server 
may also include the MGW-id in the Bearer Information message (bullet 6 in figure 6.6). 

NOTE: The incoming side bearer establishment may take place either before or after HLR interrogation. 

6.2.1 .1 .5 Framing protocol initialisation 

In 3GPP CS CN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is estabUshed through the CN 
in a forward direction. This is established independently of the bearer establishment direction. The MGW derives the 
forward direction from information sent by the MSC server within the Establish Bearer and Prepare Bearer procedures 
[6] .The notification of bearer establishment shall not be sent until the lu/Nb UP has been initialised. 

6.2.1.1.6 Through-Connection 

During the Prepare Bearer and Establish Bearer procedures, the GMSC server will use the Change Through-Connection 
procedure to request the MGW to both-way through-connect the bearer termination (bullet 4 and bullet 5 in figure 6.6). 

6.2.1 .1 .7 Confirmation of bearer establishment 

If the lAM which was sent to the succeeding node indicated that the Continuity message will follow, the Continuity 
message shall be sent when both of the following conditions are satisfied: 

1. Either: 

a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received from the preceding node (bullet 8 in figure 6.6), or 

b. The incoming lAM did not indicate that the Continuity message will follow; 

2. Either: 

a. The GMSC server has selected an MGW, and a notification of successful bearer estabUshment in the 
incoming side has been received from the MGW (bullet 7 in figure 6.6), or 
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b. MGW selection is not required for this call. 

6.2.1 .1 .8 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The GMSC server shall request the activation of the voice processing functions in the bearer terminations. 
For non-speech calls, the GMSC server has the ability to instruct the MGW to disable the voice processing functions 
(buUet 13 in figure 6.6). The voice activation request from the GMSC server to MGWa may be issued as soon as bullet 
8 in figure 6.6, and may be issued as late as buUet 13 in figure 6.6 as illustrated. 

6.2.1 .1 .9 Failure handling in GMSC server 

If any procedure between the GMSC server and the MGW has not completed successfully or the GMSC server receives 
a Bearer Released procedure from the MGW, the call shall be cleared as described in clause 7.3, (G)MSC server 
initiated caU clearing or in clause 7.4, MGW initiated call clearing. Alternatively, the GMSC server may only release 
the resources in the MGW that caused the failure, possibly select a new MGW for the bearer coimection and continue 
the call establishment using new resources in the selected MGW. 

6.2.1.2 MSG server 

6.2.1.2.1 Paging 

If the network side bearer estabUshment is delayed whilst the paging procedure is completed, the MSC server starts the 
Start_Bearer_EstabUshment timer when the paging procedure is started. The Start_Bearer_Establishment timer is 
stopped when the paging procedure is completed, or optionally when the Call Confirmed message is received in 
accordance with 3GPP TS 23.153 [3]. If the Start_Bearer_Establishment timer expires, the MSC server starts the 
network side bearer establishment. 

6.2.1.2.2 Call setup 

The MSC server indicates to the UE in the SETUP message that early access bearer assignment is used in order to 
establish the bearer end-to-end before the UE starts alerting. The MSC server indicates to the UE in SETUP message 
that early access bearer assignment is used if either of the following conditions is satisfied before sending the SETUP 
message (bullet 2 in figure 6.6): 

1 . The incoming lAM indicated that the Continuity message will follow, but no Continuity message has been 
received; 

2. A notification of successful bearer estabUshment in the network side has not been received from the MGW. 

6.2.1.2.3 MGW selection 

The MSC server shall select an MGW for the bearer connection before it performs the network side bearer 
establishment or the access bearer assignment. This happens at latest after the UE has sent the Call Confirmed message. 
If the MSC server received an MGW-id from the preceding node, it may use this for the MGW selection (bullet 3 in 
figure 6.6). For GSM, if performing Service based handover (see 3GPP TS 48.008 [27]) the MSC Server may omit 
MGW selection at this time. 

6.2.1 .2.4 Network side bearer establishment 

The MSC server requests the MGW to prepare for the network side bearer estabUshment using the Prepare Bearer 
procedure. The MSC server requests the MGW to provide a bearer address, a binding reference and to notify when the 
bearer is established (bullet 3 in figure 6.6). The MSC server also provides the MGW with the bearer characteristics that 
was received from the preceding node in the lAM. After the MGW has replied with the bearer address and the binding 
reference, the MSC server provides the Bearer Information message to the preceding node. The MSC server may also 
provide the MGW-id in the Bearer Information message. 

6.2.1 .2.5 Access bearer assignment 

The access bearer assignment shall be started only when both of the following conditions are satisfied: 
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1. Either: 

a. The incoming lAM indicated that the Continuity message will foUow, and a Continuity message has been 
received from the preceding node, or 

b. The incoming JAM did not indicate that the Continuity message will foUow; 

2. A notification of successful bearer establishment in the network side has been received from the MGW (bullet 6 
in figure 6.6). 

The MSC server shall select bearer characteristics for the access bearer. 

For the access bearer assignment in UMTS the MSC server requests the MGW to prepare for the access bearer 
establishment using the Prepare Bearer procedure. The MSC server requests the MGW to provide a bearer address and a 
binding reference, provides the MGW with the bearer characteristics and requests notification that the bearer can be 
modified. For speech calls, the MSC server shall provide the MGW with the speech coding information and 
conditionally GTT related information in accordance with 3GPP TS 23.226 [28J for the bearer. For a non-speech call 
the MSC server also provides the MGW with a PLMN Bearer Capability [4]. After the MGW has replied with the 
bearer address and the binding reference the MSC server requests the access bearer assignment using the provided 
bearer address and the binding reference (bullet 9 in figure 6.6) in accordance with 3GPP TS 25.413 [26]. The MSC 
shall only be notified by the MGW using the Bearer Modification Support procedure if the existing link characteristics 
of the access bearer can be modified at a later stage, see subclause 13.18.1. 

For GERAN lu mode the MSC Server receives the GERAN capabihties within the RANAP INITIAL UE MESSAGE, 
indicating the services (e.g. for CS speech services the supported codec types and, for an adaptive codec type, the 
supported codec modes (for definition see [27])), which will be available at the RAB establishment procedure. The 
MSC server shall take the indicated GERAN capabihties into account as well as the received MS capabilities when 
negotiating a service. Additionally, when requesting the access bearer assignment the MSC server shall indicate to the 
GERAN the selected service (e.g. selected codec type). The MSC server shall not set codec information in the NAS 
Synchronisation Indicator (see [4]). Instead it shall set codec information in the GERAN BSC container. 

For GSM, before the MSC server starts the access bearer assignment, the MSC server uses the Reserve Circuit 
procedure to seize a TDM circuit. For a non-speech call the MSC server also provides the MGW with a PLMN Bearer 
Capability [4] and a GSM channel coding. After the MGW has replied the TDM circuit seizure the MSC server requests 
access bearer assignment (bullet 10 in figure 6.6) in accordance with 3GPP TS 48.008 [27]. If performing Service based 
handover (see 3GPP TS 48.008 [27]) the MSC Server may omit to perform Reserve Circuit procedure. 

6.2.1.2.6 Framing protocol initialisation 

In 3GPP CS CN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is estabhshed through the CN 
in a forward direction. This is estabhshed independently of the bearer estabhshment direction. The MGW derives the 
forward direction from information sent by the MSC server within the Establish Bearer and Prepare Bearer procedures 
[6]. The notification of bearer establishment shall not be sent until the Nb UP has been initialised. 

6.2.1 .2.7 Called party alerting 

For a speech call, when the MSC server receives an Alerting message, it requests the MGW to provide a ringing tone to 
the calling party using the Send Tone procedure (buUet 1 1 in figure 6.6). 

NOTE: Other kind of tones may be provided to the calhng party at an earlier stage of the call estabhshment. 

6.2.1 .2.8 Called party answer 

For a speech call, when the MSC server receives a Connect message, it requests the MGW to stop providing the ringing 
tone to the calhng party using the Stop Tone procedure (bullet 12 in figure 6.6). 

6.2.1.2.9 Through-Connection 

During the Prepare Bearer and Reserve Circuit procedures, the MSC server will use the Change Through-Connection 
procedure to request the MGW to through-connect the bearer terminations so that the bearer will be not 
through-connected (bullet 3, and bullet 9 or 10 in figure 6.6). 
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When the MSC server receives the Connect message, it requests the MGW to both-way through-connect the bearer 
using the Change Through-Connection procedure (bullet 12 in figure 6.6). 



6.2.1.2.10 Interworking function 

The MGW may use an interworking function that is based on the PLMN Bearer Capability [4] of the bearer 
termination. The activation of the possible interworking function in both bearer terminations will be requested by the 
MSC server at reception of the Connect message using the Activate Interworking Function procedure (bullet 12 in 
figure 6.6). 



6.2.1.2.11 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 



6.2.1.2.12 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The MSC server shall request the activation of the voice processing functions in the bearer terminations. 
For non-speech calls, the MSC server has the ability to instruct the MGW to disable the voice processing functions 
(bullet 12 in figure 6.6). 



6.2.1.2.13 Failure handling in MSC server 

If any procedure between the MSC server and the MGW is not completed successfully, the call shall be cleared as 
described in clause 7.3, (G)MSC server initiated call clearing. Alternatively, the MSC server may only release the 
resources in the MGW that caused the failure, possibly select a new MGW for the bearer connection and continue the 
call establishment using new resources in the selected MGW. 



6.2.1.2.14 Example 

Figure 6.5 shows the network model for the basic mobile terminating call. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A-interface) 
and the bearer. The MSC server seizes one context with two bearer terminations in MGWb. The bearer termination Tl 
is used for the bearer towards the RNC/BSC and the bearer termination T2 is used for the bearer towards the GMSC 
server selected MGWa. The GMSC server seizes one context with two bearer terminations in MGWa. The bearer 
termination T3 is used for the bearer towards the MSC server selected MGWb and the bearer termination T4 is used for 
the bearer towards the preceding MGW. 



GMSC-S 





MSC-S 






^ CTX2 ^ ^ CTXl ^ ^-JRNC/BSCr 



MGWa 



MGWb 



Figure 6.5: Basic IVIobile Terminating Call Forward Bearer Establishment 

(network model) 

Figure 6.6 shows the message sequence example for the basic mobile terminating call. In the example the GMSC server 
requests seizure of the outgoing side bearer termination and establishment of the bearer when the Bearer Information 
message is received from the MSC server. After the outgoing side bearer termination is seized the GMSC server 
requests seizure of the incoming side bearer termination. The MGW sends a notification of an established incoming side 
bearer. The MSC server requests seizure of the network side bearer termination when Call Confirmed message is 
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received from the UE. The MGW sends a notification of an established network side bearer. When the Continuity 
message is received from the GMSC server, the MSC server requests seizure of the access side bearer termination. For a 
speech call the MSC server requests MGW to provide a ringing tone to the calling party at alerting. At answer the MSC 
server requests MGW to both-way through-connect the bearer. For a speech call the MSC server requests MGW to stop 
the ringing tone to the calling party at answer. When the MSC server receives an answer indication, it shall request the 
possible activation of the interworking function in both bearer terminations. The (G)MSC server shall request the 
possible activation of the voice processing functions for the bearer terminations. 
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Figure 6.6/1 : Basic IVIobile Terminating Call, Forward Bearer Establishment 

(message sequence chart) 
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Figure 6.6/2: Basic IVIobile Terminating Call, Forward Bearer Establishment 
(message sequence chart continue) 
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6.2.2 Backward bearer establishment 

The basic mobile terminating call shall be estabUshed in accordance with 3GPP TS 23.108 [4]. The following clauses 
describe the additional requirements for the bearer independent CS core network. If out-of-band transcoder control is 
apphed for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 

6.2.2.1 GMSC server 

6.2.2.1.1 MGW selection 

The GMSC server shall select an MGW for the bearer connection before it performs the incoming side bearer 
establishment or the outgoing side bearer establishment. This happens before sending the 1AM. If the GMSC server 
received an MGW-id from the preceding node, it may use this for the MGW selection (bullet 1 in figure 6.8). 

NOTE 1: As an implementation option, if there is no need for the GMSC server to manipulate the bearer, the 

GMSC server may perform call control signalling without any associated MGW. In that case the bearer 
related information shall be provided transparently through the GMSC server. 

6.2.2.1 .2 Outgoing side bearer establisliment 

The GMSC server shall select bearer characteristics for the outgoing side bearer cormection before it sends the lAM. 
The GMSC server requests the MGW to prepare for the outgoing side bearer establishment using the Prepare Bearer 
procedure. The GMSC server requests the MGW to provide a bearer address and a binding reference, and provides the 
MGW with the bearer characteristics (bullet 3 in figure 6.8). After the MGW has replied with the bearer address and the 
binding reference, the GMSC server sends the lAM to the succeeding node. 

6.2.2.1.3 Initial addressing 

The GMSC server shall indicate in the lAM that backward bearer estabUshment is to be used. The GMSC server shall 
also indicate in the lAM that the Continuity message will follow if either of the following conditions is satisfied before 
sending the I AM: 

1 . The incoming lAM indicated that the Continuity message will follow, but no Continuity message has been 

received, or 

2. The GMSC server selected an MGW, but a notification of successful bearer establishment on the incoming side 
has not been received from the MGW. 

The GMSC server shall provide the bearer characteristics to the succeeding node in the lAM. The MGW-id may also be 
provided in the LAM (bullet 4 in figure 6.8). 

6.2.2.1 .4 Incoming side bearer establishment 

The GMSC server requests the MGW to establish a bearer to the given destination MGW and to notify when the bearer 
is established using the Establish Bearer procedure. The GMSC server provides the MGW with the bearer address, the 
binding reference and the bearer characteristics that were received from the preceding node in the lAM (bullet 1 in 
figure 6.8). 

NOTE 2: The incoming side bearer establishment may take place either before or after HLR interrogation. 

6.2.2.1 .5 Framing protocol initialisation 

In 3GPP CS CN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is established through the CN 
in a forward direction. This is estabhshed independently of the bearer estabhshment direction. The MGW derives the 
forward direction from information sent by the MSC server within the EstabUsh Bearer and Prepare Bearer procedures 
[6]. The notification of bearer estabUshment shall not be sent until the lu/Nb UP has been initiaUsed 
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6.2.2.1.6 Through-Connection 

During the Prepare Bearer and Establish Bearer procedures, the GMSC server will use the Change Through-Connection 
procedure to request the MGW to both-way through-connect the bearer termination (bullet 1 and bullet 3 in figure 6.8). 

6.2.2.1 .7 Confirmation of bearer establishment 

If the lAM which was sent to the succeeding node indicated that the Continuity message will follow, the Continuity 
message shall be sent when both of the following conditions are satisfied: 

1. Either: 

a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received from the preceding node, or 

b. The incoming lAM did not indicate that the Continuity message will follow; 

2. Either: 

a. The GMSC server has selected an MGW, and a notification of successful bearer establishment in the incoming 
side has been received from the MGW (bullet 2 in figure 6.8), or 

b. MGW selection is not required for this call. 

6.2.2.1 .8 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The (G)MSC server shall request the activation of voice processing functions in the bearer terminations. 
For non-speech calls, the GMSC server has the ability to instruct the MGW to disable the voice processing functions 
(bullet 12 in figure 6.8). The voice activation request from the GMSC server to MGWa may be issued as soon as bullet 
4 in figure 6.8, and may be issued as late as bullet 12 in figure 6.8 as illustrated. 

6.2.2.1 .9 Failure handling in GMSC server 

If any procedure between the MSC server and the MGW is not completed successfully or the GMSC server receives a 
Bearer Released procedure from the MGW, the call shall be cleared as described in clause 7.3, (G)MSC server initiated 
call clearing or in clause 7.4, MGW initiated call clearing. Alternatively, the GMSC server may only release the 
resources in the MGW that caused the failure, possibly select a new MGW for the bearer connection and continue the 
call establishment using new resources in the selected MGW. 

6.2.2.2 MSC server 

6.2.2.2.1 Paging 

If the network side bearer establishment is delayed whilst the paging procedure is completed, the MSC server starts the 
Start_Bearer_Establishment timer when the paging procedure is started. The Start_Bearer_Establishment timer is 
stopped when the paging procedure is completed, or optionally when the Call Confirmed message is received in 
accordance with 3GPP TS 23.153 [3]. If the Start_Bearer_Estabhshment timer expires, the MSC server starts the 
network side bearer establishment. 

6.2.2.2.2 Call setup 

The MSC server indicates to the UE in the SETUP message that early access bearer assignment is used in order to 
estabhsh the bearer end-to-end before the UE starts alerting. The MSC server indicates to the UE in the SETUP 
message that early access bearer assignment is used, if and only if, either of the following conditions are satisfied before 
sending the SETUP message (bullet 5 in figure 6.8): 

1 . If the lAM indicated that the Continuity message will follow, but no Continuity message has been received. 

2. A notification of successful bearer establishment in the network side has not been received from the MGW. 
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6.2.2.2.3 



MGW selection 



The MSC server shall select an MGW for the bearer connection before it performs the network side bearer 
estabUshment or the access bearer assignment. This happens at latest after the UE has sent the Call Confirmed message. 
If the MSC server received an MGW-id from the preceding node, it may use this for the MGW selection (bullet 6 in 
figure 6.8). For GSM, if performing Service based handover (see 3GPP TS 48.008 [27]) the MSC Server may omit 
MGW selection at this time. 

6.2.2.2.3 Network side bearer establisliment 

The MSC server requests the MGW to establish a bearer to the given destination MGW and to notify when the bearer is 
established using the Establish Bearer procedure. The MSC server provides the MGW with the bearer address, the 
binding reference and the bearer characteristics that were received from the preceding node in the lAM (bullet 6 in 
figure 6.8). 

6.2.2.2.4 Access bearer assignment 

The access bearer assigmnent shall be started only when both of the following conditions are satisfied: 



a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received from the preceding node, or 

b. The incoming lAM did not indicate that the Continuity message will follow; 

2. A notification of successful bearer establishment in the network side has been received from the MGW (buUet 7 in 
figure 6.8). 

The MSC server shall select bearer characteristics for the access bearer. 

For the access bearer assignment in UTRAN the MSC server requests the MGW to prepare for the access bearer 
estabhshment using the Prepare Bearer procedure. The MSC server requests the MGW to provide a bearer address and a 
binding reference, provides the MGW with the bearer characteristics and requests notification that the bearer can be 
modified. For speech calls, the MSC server shall provide the MGW with the speech coding information and 
conditionally GTT related information in accordance with 3GPP TS 23.226 [28] for the bearer. For a non-speech call 
the MSC server also provides the MGW with a PLMN Bearer CapabiUty [4]. After the MGW has replied with the 
bearer address and the binding reference the MSC server requests the access bearer assignment using the provided 
bearer address and the binding reference (bullet 8 in figure 6.8) in accordance with 3GPP TS 25.413 [26]. The MSC 
shall only be notified by the MGW using the Bearer Modification Support procedure if the existing link characteristics 
of the access bearer can be modified at a later stage, see subclause 13.18.1. 

For GERAN lu mode the MSC Server receives the GERAN capabilities within the RANAP INITIAL UE MESSAGE, 
indicating the services (e.g. for CS speech services the supported codec types and, for an adaptive codec type, the 
supported codec modes (for definition see [27])), which will be available at the RAB establishment procedure. The 
MSC server shall take the indicated GERAN capabilities into account as well as the received MS capabilities when 
negotiating a service. Additionally, when requesting the access bearer assignment the MSC server shall indicate to the 
GERAN the selected service (e.g. selected codec type). The MSC server shall not set codec information in the NAS 
Synchronisation Indicator (see [4]). Instead it shall set codec information in the GERAN BSC container.. 

For GSM, before the MSC server starts the access bearer assignment, the MSC server uses the Reserve Circuit 
procedure to seize a TDM circuit. For a non-speech call the MSC server also provides the MGW with a PLMN Bearer 
CapabiUty [4] and a GSM channel coding. After the MGW has replied the TDM circuit seizure the MSC server requests 
access bearer assignment (bullet 9 in figure 6.8) in accordance with 3GPP TS 48.008 [27]. If performing Service based 
handover (see 3GPP TS 48.008 [27]) the MSC Server may omit to perform Reserve Circuit procedure. 



In 3GPP CS CN speech and data shall be carried using the lu/Nb User Plane Protocol. The specification for the lu UP 
protocol is defined in [20] and the Nb UP Protocol in [7] and [21]. The lu/Nb UP Protocol is estabhshed through the CN 
in a forward direction. This is estabhshed independently of the bearer establishment direction. The MGW derives the 
forward direction from information sent by the MSC server within the Establish Bearer and Prepare Bearer procedures 
[6]. The notification of bearer estabhshment shall not be sent until the Nb UP has been initiahsed. 



1. 



Either: 



6.2.2.2.5 



Framing protocol initialisation 
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6.2.2.2.6 Called party alerting 

For a speech call, when the MSC server receives an Alerting message, it requests the MGW to provide a ringing tone to 
the calling party using the Send Tone procedure (bullet 10 in figure 6.8). 

NOTE: Other kind of tones may be provided to the calUng party at an earlier stage of the call estabUshment. 

6.2.2.2.7 Called party answer 

For a speech call, when the MSC server receives a Connect message, it requests the MGW to stop providing the ringing 
tone to the calUng party using the Stop Tone procedure (buUet 1 1 in figure 6.8). 

6.2.2.2.8 Through-Connection 

During any one of the Prepare Bearer, Reserve Circuit and Establish Bearer procedures, the MSC server will use the 
Change Through-Connection procedure to request the MGW to through-connect the bearer terminations so that the 
bearer will be not through-connected (bullet 6, and bullet 8 or 9 in figure 6.8). 

When the MSC server receives the Connect message, it requests the MGW to both-way through-connect the bearer 
using the Change Through-Connection procedure (bullet 11 in figure 6.8). 

6.2.2.2.9 Interworking function 

The MGW may use an interworking function that is based on the PLMN Bearer Capabihty [4] of the bearer 
termination. The activation of the possible interworking function in both bearer terminations will be requested by the 
MSC server at reception of the Connect message using the Activate Interworking Function procedure (bullet 1 1 in 
figure 6.8). 

6.2.2.2.10 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

6.2.2.2.1 1 Voice Processing function 

A voice processing function located on the MGW may be used to achieve desired acoustic quality on the bearer 
terminations. The MSC server shall request the activation of the voice processing functions in the bearer terminations. 
For non-speech calls, the MSC server has the ability to instruct the MGW to disable the voice processing functions 
(bullet 11 in figure 6.8). 

6.2.2.2.12 Failure handling in MSC server 

If any procedure between the MSC server and the MGW is not completed successfully or the MSC server receives a 
Bearer Released procedure from the MGW, the call shall be cleared as described in clause 7.3, (G)MSC server initiated 
call clearing or in clause 7.4, MGW initiated call clearing. Alternatively, the MSC server may only release the resources 
in the MGW that caused the failure, possibly select a new MGW for the bearer connection and continue the caU 
estabhshment using new resources in the selected MGW. 

6.2.2.2.13 Example 

Figure 6.7 shows the network model for the basic mobile terminating call. The "squared" Une represents the call control 
signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A-interface) 
and the bearer. The MSC server seizes one context with two bearer terminations in MGWb. The bearer termination Tl 
is used for the bearer towards the RNC/BSC and the bearer termination T2 is used for the bearer towards the GMSC 
server selected MGWa. The GMSC server seizes one context with two bearer terminations in MGWa. The bearer 
termination T3 is used for the bearer towards the MSC server selected MGWb and the bearer termination T4 is used for 
the bearer towards the preceding MGW. 
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Figure 6.7: Basic IVIobile Terminating Call, Backward Bearer Establishment 

(network model) 
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Figure 6.8 shows the message sequence example for the basic mobile terminating call. In the example the GMSC server 
requests seizure of the incoming side bearer termination and establishment of the bearer first. After a notification of 
incoming side bearer establishment has been received from the MGW, the GMSC server requests seizure of the 
outgoing side bearer termination. The MSC server requests seizure of the network side bearer termination and 
establishment of the bearer when the Call Confirmed message is received from the UE. After a notification of the 
network side bearer establishment has been received from the MGW the MSC server requests seizure of the access side 
bearer termination. For a speech call. When the MSC server receives an alerting message, it requests MGW to provide a 
ringing tone to the calling party. When the MSC server receives an answer indication, it requests MGW to both-way 
through-connect the bearer. For a speech, when the MSC server receives an answer indication, it requests MGW to stop 
the ringing tone to the calling party and requests the possible activation of the interworking function in both bearer 
terminations. The (G)MSC server shall request the possible activation of the voice processing functions for the bearer 
terminations. 
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Figure 6.8/1 : Basic lUlobile Terminating Call, Backward Bearer Establishment 

(message sequence chart) 
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Figure 6.8/2: Basic lUlobile Terminating Call, Backward Bearer Establishment 
(message sequence chart continue) 
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6.2.3 Terminating Call Establishment For lu Interface on IP 

If luCS on IP is supported by the MSC server, the Core Network side procedures described in 6.2.1 or 6.2.2 shall apply. 
For the access bearer termination, the exchange of IP addresses via call control procedures is described in this clause. 

Before the MSC server starts the access bearer assignment, the MSC server requests the MGW to prepare for the access 
bearer using the Prepare_IP_Transport procedure. The MSC server requests the MGW to provide an IP Transport 
Address and UDP Port and provides the MGW with the bearer characteristics. For speech calls, the MSC server shall 
provide the MGW with the speech coding information and conditionally GTT related information in accordance with 
3GPP TS 23.226 [28]. For a non-speech call the MSC server also provides the MGW with a PLMN Bearer Capability 
[4]. After the MGW has replied with the IP address and UDP Port the MSC server requests access bearer assignment 
using the provided IP address and UDP Port in accordance with 3GPP TS 25.413 [26]. The IP addresses and UDP Ports 
of the MGW and the RNC are exchanged via the RANAP procedures. If the bearer transport is IP and luUP mode is 
Transparent, when the MSC receives the RANAP RAB assignment response it shall send the RNC IP address and UDP 
Port to the MGW Access bearer termination using the Modify_IP_Transport_Address procedure. 

If the bearer transport is IP and luUP mode is Support, the MGW shall use the source IP address and UDP Port of the 
luUP Init packet received from the radio access network as the destination address for subsequent downlink packets. 

The sequence is shown in figure 6.2.3/1. 
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Figure 6.2.3/1 Terminating Call Establishment For lu Interface on IP 
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6.2.4 Terminating Call Establishment For A Interface over IP 

If AoIP is supported by the MSC server, the Core Network side procedures described in 6.2.1 or 6.2.2 shall apply. For 
the access side termination, the exchange of IP addresses via call control procedures is described in this clause. 

Before the MSC server sends the Assignment Request to the BSC, the MSC server requests the MGW to reserve an 
RTF bearer termination using the Reserve RTF Connection Foint procedure. The MSC server requests the MGW to 
reserve an IF Address and UDF Fort and also may indicate that the IF interface type is for A interface over IF. The 
MGW reserves the AoIF termination and indicates the IF address and UDF port number to the MSC server. MSC server 
then requests access bearer assignment using the provided IF address and UDF Fort. When MSC server receives the 
BSSMAF ASSIGNMENT COMFLETE message, it shall send the BSC IF address and UDF Fort to the MGW Access 
bearer termination using the Configure RTF Connection Point procedure. 

The sequence is shown in figure 6.2.3/1. 
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Figure 6.2.3/1 Terminating Call Establishment For AoIP 



7 Call Clearing 

NOTE: All message sequence charts in this clause are examples. All valid call establishment message sequences 
can be derived from the example message sequences and associated message pre-conditions. 
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7.1 Network Initiated 

The tenns "incoming" and "outgoing" in the following text refers to the direction of propagation of the Release 
message, not to the direction of estabhshing the original call. 

7.1.1 GIVISC server 

7.1 .1 .1 Call clearing from the incoming side 

Once the Release message has been received from the preceding node, the GMSC server releases any MGW allocated 
resources for the incoming side. If any resources were seized in the MGW, the GMSC server shall use the Release 
Bearer and Release Termination procedures to indicate to the MGW to remove the incoming side bearer termination 
and that the bearer can be released towards the preceding MGW. After the resources in the MGW are released the 
GMSC server sends the Release Complete message to the preceding node. 

7.1 .1 .2 Call clearing to the outgoing side 

The GMSC server sends the Release message to the succeeding node. Once the succeeding node has sent the Release 
Complete message, the GMSC server releases any MGW allocated resources for the outgoing side. If any resources 
were seized in the MGW, the GMSC server shall use the Release Bearer and Release Termination procedures to 
indicate to the MGW to remove the outgoing side bearer termination and that the bearer can be released towards the 
succeeding MGW. 

7.1.2 IVISC server 

The network initiated call clearing shall be performed in accordance with 3GPP TS 23.108 [18]. The following clauses 
describe the additional requirements for the bearer independent CS core network. 

7.1 .2.1 Call clearing from the network side 

Once the Release message has been received from the preceding/succeeding node, the MSC server releases any MGW 
allocated resources for the network side. If any resources were seized in the MGW, the MSC server shall use the 
Release Bearer and Release Termination procedures to indicate to the MGW to remove the network side bearer 
termination and that the bearer can be released towards the preceding/succeeding MGW. After the resources in the 
MGW are released the MSC server sends the Release Complete message to the preceding/succeeding node (bullet 1 in 
figure 7.2). 

7.1 .2.2 Call clearing to the UE 

The MSC server initiates call clearing towards the UE and requests release of the associated radio resources as 
described in 3GPP TS 23.108[18]. Once the call clearing and the release of the associated radio resources have been 
completed, the MSC server releases any MGW allocated resources for the access side. If any resources were seized in 
the MGW, the MSC server uses the Release Termination procedure to requests the MGW to remove the access side 
bearer termination (bullet 2 or bullet 3 in figure 7.2). 
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7.1.2.3 Example 

Figure 7.1 shows the network model for a network initiated clearing of the mobile call. The "squared" line represents 
the call control signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for 
the A-interface) and the bearer. The MSG server seizes one context with two bearer terminations in the MGW. Bearer 
termination Tl is used for the bearer towards RNG/BSG and bearer termination T2 is used for the bearer towards 
succeeding MGW. 




V J 



Figure 7.1 : Network Initiated Call Clearing (Network model) 

Figure 7.2 shows the message sequence example for the network initiated clearing of a mobile call. In the example the 
when the call clearing indication is received from the preceding/succeeding node, MSG server indicates that the 
network bearer can be released and to release the network side bearer termination. After the release of the network side 
bearer termination the MSG server indicates to the preceding/succeeding node that call clearing has been completed. 
The MSG server initiates call clearing towards the UE and requests release of the radio resource. After the response of 
the radio resource release is received then the MSG server requests release of the access side bearer termination. 
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Figure 7.2: Network Initiated Call Clearing (message sequence chart) 



7.2 User Initiated 

The user initiated call clearing shall be performed in accordance with 3GPP TS 23.108 [18]. The following clauses 
describe the additional requirements for the bearer independent CS core network. 
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7.2.1 Void 

7.2.2 MSG server 

7.2.2.1 all clearing from the UE 

The UE initiated call clearing is performed and the release of the associated radio resources is performed as described in 
3GPP TS 23.108 [18]. Once the call clearing and the associated radio resources release have been completed, the MSG 
server releases any MGW allocated resources for the access side. If any resources were seized in the MGW the MSG 
server uses the Release Termination procedure to requests the MGW to remove the access side bearer termination 
(bullet 1 or bullet 2 in figure 7.4). 

7.2.2.2 Call clearing to the network side 

The MSG server sends the Release message to the preceding/succeeding node. Once the preceding/succeeding node has 
sent the Release Gomplete, the MSG server releases any MGW allocated resources for the network side. If any 
resources were seized in the MGW server shall use the Release Bearer and Release Termination procedures to indicate 
to the MGW to remove the network side bearer termination and that the bearer can be released towards the 
preceding/succeeding MGW (bullet 3 in figure 7.4). 

7.2.2.3 Example 

Figure 7.3 shows the network model for a user initiated clearing of a mobile call. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb mode for the A- 
interface) and the bearer. The MSG server seizes one context with two bearer terminations in the MGW. Bearer 
termination Tl is used for the bearer towards RNG/BSC and bearer termination T2 is used for the bearer towards 
succeeding MGW. 
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Figure 7.3: User Initiated Call Clearing (Network model) 

Figure 7.4 shows the message sequence example for the user initiated clearing of a mobile call. In the example the UE 
initiates call clearing towards the MSG server and the MSG server requests release of the radio resource. After the 
response of the radio resource release is received the MSG server requests the release of the access side bearer 
termination. The MSG server initiates call clearing towards the preceding/succeeding node. Once the 
preceding/succeeding node has indicated that call clearing has been completed, the MSG server indicates that the 
network bearer can be released and to release the network side bearer termination. 
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Figure 7.4: User Initiated Call Clearing (message sequence chart) 

(G)MSC server Initiated 



The following clauses describe the additional requirements for (G)MSC server initiated call clearing in the bearer 
independent CS core network. 

7.3.1 GIVISC server 

7.3.1 .1 Call clearing to the destination side 

If the call is already established towards the destination, call clearing is performed as described in clause 7.1.1, call 
clearing to the outgoing side. 

7.3.1 .2 Call clearing to the originating side 

The call clearing to the originating side is performed as described in clause 7.1.1, call clearing to the outgoing side. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



57 



ETSI TS 123 205 V9.2.0 (2011-04) 



7.3.2 MSG server 

7.3.2.1 Call clearing to the UE 

The call clearing to the UE is performed as described in clause 7.1.2, call clearing to the UE (bullet 1 and bullet 2 in 
figure 7.6). 

7.3.2.2 Call clearing to the network side 

If the call is already established towards the network side, the call clearing to the network side is performed as described 
in clause 7.2.2, call clearing to the network side (bullet 3 in figure 7.6). 

7.3.2.3 Example 

Figure 7.5 shows the network model for the MSC server initiated clearing of the mobile call. The "squared" line 
represents the call control signalling. The "dotted" line represents the bearer control signalling (not applicable in A/Gb 
mode for the A-interface) and the bearer. The MSC server seizes one context with two bearer terminations in the MGW. 
Bearer termination Tl is used for the bearer towards RNC/BSC and bearer termination T2 is used for the bearer towards 
succeeding MGW. 




V J 



Figure 7.5: MSC Server Initiated Call Clearing (Network model) 

Figure 7.6 shows the message sequence example for the MSC server initiated clearing of a mobile call. In the example 
the MSC server initiates call clearing of the network side and the access side. After the call clearing towards the UE and 
the release of the radio resource have been completed the MSC server requests release of the access side bearer 
termination. Once the preceding/succeeding node has indicated that call clearing has been completed, the MSC server 
indicates that the network bearer can be released and to release the network side bearer termination. 
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Figure 7.6: MSC Server Initiated Call Clearing (message sequence chart) 
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7.4 MGW Initiated 

The following clauses describe the additional requirements for MGW initiated call clearing in the bearer independent 
CS core network. 

7.4.1 GIVISC server 

7.4.1 .1 Bearer released on the destination side 

After the GMSC server has received the Bearer Released procedure from the MGW, it shall send the Release message 
to the succeeding node. Once the succeeding node has sent the Release Complete message, the GMSC server releases 
any MGW allocated resources for the destination side. The GMSC server uses the Release Termination procedure to 
request the MGW to remove the destination side bearer termination. 

The call clearing to the incoming side is performed as described in clause 7.1.1.2, call clearing to the outgoing side. 

7.4.1 .2 Bearer released on the originating side 

After the GMSC server has received the Bearer Released procedure from the MGW, the GMSC server sends the 
Release message to the preceding node. Once the preceding node has sent the Release Complete message, the GMSC 
server releases any MGW allocated resources for the originating side. The GMSC server uses the Release Termination 
procedure to request the MGW to remove the originating side bearer termination. 

If the call is already established towards the destination side, call clearing to the destination side is performed as 
described in clause 7.1.1.2, call clearing to the outgoing side. 

7.4.2 IVISC server 

7.4.2.1 Bearer released on the access side 

After the MSC server has received the Bearer Released procedure from the MGW, the MSC server initiates the call 
clearing towards the UE and requests release of the allocated radio resources as described in 3GPP TS 23.108 [18]. 
Once the call clearing and the radio resources release have been completed, the MSC server releases any MGW 
allocated resources for the access side. The MSC server uses the Release Termination procedure to request the MGW to 
remove the access side bearer termination. 

If the call is already established towards the network side, call clearing to the network side is performed as described in 
clause 7.2, call clearing to the network side. 

7.4.2.2 Bearer released on the network side 

After the MSC server has received the Bearer Released procedure from the MGW, the MSC server sends the Release 
message to the preceding/succeeding node. Once the preceding/succeeding node has sent the Release Complete 
message, the MSC server releases any MGW allocated resources for the network side. The MSC server uses the Release 
Termination procedure to request the MGW to remove the network side bearer termination (bullet 1 and bullet 2 in 
figure 7.8). 

Call clearing to the UE is performed as described in clause 7.1.2.2, call clearing to the UE (bullet 3 in figure 7.8). 

7.4.2.3 Example 

Figure 7.7 shows the network model for an MGW initiated clearing of a mobile call. The "squared" line represents the 
call control signalling. The "dotted" hne represents the bearer control signalhng (not apphcable in A/Gb mode for the 
A-interface) and the bearer. The MSC server seizes one context with two bearer terminations in the MGW. Bearer 
termination Tl is used for the bearer towards RNC/BSC and bearer termination T2 is used for the bearer towards 
succeeding MGW. 
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Figure 7.7: MGW Initiated Call Clearing (Network model) 

Figure 7.8 shows the message sequence example for the MGW initiated clearing of a mobile call. After the MSG server 
is notified that the MGW has released the network side bearer, the MSG server initiates call clearing of the network side 
and the access side. After the call clearing towards the UE and the radio resource release have been completed the MSG 
server requests release of the access side bearer termination. Once the preceding/succeeding node has indicated that call 
clearing has been completed, the MSG server requests the release of the network side bearer termination. 
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Figure 7.8: MGW Initiated Call Clearing (message sequence chart) 

7.5 Call Clearing for lu Interface on IP 

Procedures for Call Clearing where the lu Interface is on IP are as described in sections 7.1 to 7.4, with the exception 
that only the Access side procedures apply and the Release Bearer procedure is not sent. For lu Interface on IP, the 
Release Termination procedures for IP are used to clear the MGW termination from the (G)MSC. 
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Example 

Figure 7.9 shows the network model for a network initiated clearing of the mobile call when IP transport is used on the 
lu interface. The 'squared' line represents the call control signalling. The 'dotted' line represents the bearer. The MSC 
server releases one context with two bearer terminations in the MGW. Bearer termination Tl is used for the bearer 
towards RNC/BSC and bearer termination T2 is used for the bearer towards succeeding MGW. 
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Figure 7.9 Network Initiated Call Clearing (Network model) 

Figure 7.10 shows the message sequence example for the network initiated clearing of a mobile call when IP transport 
is used on the lu Interface. In the example when the call clearing indication is received from the preceding/succeeding 
node, MSC server indicates that network bearer can be released and to release the network side bearer termination. 
After the release of the network side bearer termination the MSC server indicates to the preceding/succeeding node that 
call clearing has been completed. The MSC server initiates call clearing towards the UE and requests release of the 
radio resource. After the response of the radio resource release is received then the MSC server requests release of the 
access side bearer termination. 
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Figure 7.10 Network Initiated Call Clearing (message sequence chart) 



8 Handover/Relocation 

NOTE: All message sequence charts in this clause are examples. All valid handover/relocation message 

sequences can be derived from the example message sequences and associated message pre-conditions. 



8.1 



UMTS to UMTS 



In the context of the following clauses, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an UE in lu mode. 



8.1.1 



Intra-MSC SRNS/SBSS Relocation 



The procedures specified in 3GPP TS 23.009 [8] for "Intra-3G_MSC SRNS Relocation" shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. 
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8.1.1.1 Relocation Required 

When the Relocation Required message is received, the MSC server requests the MGW to provide a binding reference 
and a bearer address, using the Prepare Bearer procedure. For speech calls, the MSC server shall provide the MGW 
with the speech coding information for the bearer. For non-speech calls the MSC server also provides the MGW with 
the same PLMN Bearer Capability [4] as was provided at the last access bearer assignment. The MSC server uses the 
Change Flow Direction Procedure to request the MGW to set the Handover Device to initial state. The MSC server 
sends the Relocation Request message, containing the bearer address and the binding reference, to RNC-B (bullet 1 in 
figure 8.2/1). 

For Relocation towards GERAN lu mode the GERAN capabiUties of the target cell will be indicated to the MSC-Server 
within the RANAP RELOCATION REQUIRED message if the target cell provides different capabilities than the 
current cell. If no information about the GERAN capabilities of the target cell are received within this message, the 
MSC-Server shall assume that the GERAN target cell will provide the same capabilities as the current cell (for details 
see [29]). The MSC server shall indicate to GERAN the selected services within the RANAP RELOCATION 
REQUEST message. The MSC server shall not set codec information in the NAS Synchronisation Indicator (see [4]). 
Instead it shall set codec information in the GERAN BSC container. 

8.1 .1 .2 Relocation Command/Relocation Detect 

When the MSC server sends the Relocation Command message or alternatively if it receives the Relocation Detect 
message, the MSC server uses the Change Flow Direction procedure to request the MGW to set the Handover Device to 
intermediate state (bullet 2 in figure 8.2/1). 

8.1 .1 .3 Relocation Complete 

When the MSC server receives the Relocation Complete message, it requests RNC-A to release the lU. The MSC server 
also requests the MGW to set the Handover Device to its final state by removing the bearer termination towards 
RNC-A, using the Release Termination procedure (bullet 3 in figure 8.2/2). 

8.1 .1 .4 Interworking function 

The interworking function used by the MGW before relocation will also be used after relocation. 

8.1.1.5 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.1 .1 .6 Voice Processing function 

After relocation, the MGW may continue or modify voice-processing function(s) provided to each bearer termination. 

8.1 .1 .7 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers all procedures related to the handhng of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 

8.1 .1 .8 Failure Handling in MSC server 

When a procedure between the MSC server and the MGW fails the MSC server shall handle the failure as an internal 
error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have been already seized at 
the target access side then the resources shall be released using the Release Termination procedure. If the call is to be 
cleared, then it shall be handled as described in clause 7.3. 

8.1.1.9 Example 

Figure 8.1 shows the network model for the Intra-MSC SRNS Relocation. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling and the bearer. The bearer termination Tl is used 
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for the bearer towards RNC-A, bearer termination T3 is used for the bearer towards RNC-B and the bearer termination 
T2 is used for the bearer towards the succeeding/preceding MGW. 




V J 

Before Relocation: 




During Relocation: 




V y 



After Relocation: 
Figure 8.1 : Intra-MSC SRNS Relocation (network model) 

Figure 8.2 shows the message sequence example for the Intra-MSC SRNS Relocation. 

It is assumed that the Handover Device is located in the MGW, which has been selected for the call establishment by 
the MSG server. The MSG server controls the call and the mobility management. It is also assumed that only one bearer 
has been established towards RNG-A. 

In the example the MSG server requests seizure of RNG-B side bearer termination with specific flow directions. The 
MSG server orders the establishment of the bearer by sending Relocation Request towards RNG-B. When the relocation 
is detected in RNG-B the MSG server requests to change the flow directions between the terminations within the 
context. When the MSG server receives a Relocation Complete indication from RNG-B it orders RNG-A to release the 
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lU. This action causes release of the bearer between the RNC and the MGW. Finally the MSG server requests the 
MGW to release RNC-A side bearer termination. 
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Figure 8.2/1 : Intra-MSC SRNS Relocation (message sequence chart) 
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Figure 8.2/2: Intra-MSC SRNS Relocation (message sequence chart) 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



67 



ETSI TS 123 205 V9.2.0 (2011-04) 



8.1 .2 Basic Inter-MSC SRNS/SBSS Relocation 

The procedures specified in 3GPP TS 23.009 [8] for "Basic Relocation Procedure Requiring a Circuit Connection 
between 3G_MSC-A and 3G_MSC-B" shall be followed. The following clauses describe the additional requirements 
for the bearer independent CS core network. 

8.1.2.1 MSC-A/MGW-A 

8.1.2.1.1 Relocation Required 

For Relocation towards GERAN lu mode the GERAN capabilities of the target cell will be indicated to the MSC-A 
server within the RANAP RELOCATION REQUIRED message if the target cell provides different capabilities than the 
current cell. If no information about the GERAN capabilities of the target cell are received within this message, the 
MSC-A server shall assume that the GERAN target cell will provide the same capabilities as the current cell (for details 
see |29|). 

The MSC-A server shall indicate to the MSC-B server the GERAN capabilities of the target cell, if available, with the 
MAP Prepare Handover request. For speech calls, the MSC-A server shall additionally indicate to the MSC-B server the 
selected codec, the Ust of supported codecs, and the currently used codec. 

Furthermore, the MSC-A server shall indicate to the GERAN the selected service within the RANAP RELOCATION 
REQUEST message and shall set the RAB parameters within the RANAP RELOCATION REQUEST message 
according to the selected service. The MSC server shall not set codec information in the NAS Synchrorusation Indicator 
(see [4]). Instead it shall set codec information in the GERAN BSC container.. 

8.1 .2.1 .2 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment is as described for a Basic Mobile Originating Call, using either forward or 
backward bearer establishment. For speech calls, the MSC-A server shall provide the MGW-A with the speech coding 
information for the bearer. For non-speech calls, the MSC-A server shall provide MGW-A with the same PLMN Bearer 
Capability [4J as was provided at the last access bearer assignment. The MSC-A server also uses the Change Flow 
Direction procedure to request MGW-A to set the Handover Device to initial state (bullet 3 in figure 8.4/1). 

8.1 .2.1 .3 Relocation Command/Relocation Detect 

When the MSC-A server sends the Relocation Conomand message or alternatively if it receives the Relocation Detect 
message, the MSC-A server uses the Change Flow Direction procedure to requests MGW-A to set the Handover Device 
to intermediate state (bullet 4 in figure 8.4/2). 

8.1.2.1.4 Relocation Complete 

When the MSC-A server receives the Relocation Complete message, it requests RNC-A to release the lU. The MSC-A 
server also requests MGW-A to set the Handover Device to its final state by removing the bearer termination towards 
RNC-A, using the Release Termination procedure (bullet 5 in figure 8.4/2). 

8.1 .2.1 .5 Interworking function 

The interworking function used by MGW-A before relocation will also be used after relocation. 

8.1.2.1.6 Codec handling 

The MGW may include a speech transcoder based upon the speech coding irrformation provided to each bearer 
termination. 

8.1 .2.1 .7 Voice Processing function 

Voice processing function(s) provided by MGW-A before relocation, may be modified or disabled by MGW-A after 
relocation. 
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8.1 .2.1 .8 Handling of multiple bearers (multicall) 

If the UE is engaged with muhiple bearers all procedures related to the handUng of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 

8.1 .2.1 .9 Failure Handling in MSG server 

When a procedure between the MSC-A server and MGW-A fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 123]. If call establishment towards MSC-B 
has already started then the call towards MSC-B server shall be cleared as described in clause 7.3. If the original call is 
to be cleared, then it shall be handled as described in clause 7.3. 

8.1.2.2 MSC-B/MGW-B 

8.1.2.2.1 MGW selection 

The MSC-B server selects an MGW when it receives Prepare Handover Request message (bullet 1 in figure 8.4/1). 

8.1 .2.2.2 Bearer establishment towards RNC-B 

When the MSC-B server has selected MGW-B it requests MGW-B to provide a binding reference and a bearer address, 
using the Prepare Bearer procedure. For speech calls, the MSC-B server shall provide the MGW-B with the speech 
coding information for the bearer. The MSC-B server sends the Relocation Request message to the RNC-B containing 
the bearer addresses and binding references (bullet 2 in figure 8.4/1). 

For Relocation towards GERAN lu mode, if the selected service is speech and the MSC-B server carmot provide the 
codec requested by the MSC-A server, the MSC-B server shall select another codec according to the received GERAN 
capabilities of the target cell and the received list of supported codecs, and shall set the RAB parameters within the 
RANAP RELOCATION REQUEST message according to the new selected codec. Furthermore, the MSC-B server 
shall report the chosen codec and codec modes back to the MSC-A server with MAP Prepare Handover response. 

8.1 .2.2.3 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment is as described at Basic Mobile Terminating Call, using either forward or 
backward bearer establishment. 

8.1.2.2.4 Codec handling 

The MGW may include a speech transcoder based upon the speech coding irrformation provided to each bearer 
termination. 

8.1 .2.2.5 Voice Processing function 

Voice processing function(s) provided by MGW-A before relocation, may be continued or modified by MGW-B after 
relocation. 

8.1 .2.2.6 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers all procedures related to the handling of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 

8.1 .2.2.7 Failure Handling in MSG server 

When a procedure between the MSC-B server and MGW-B fails the MSC-B server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-B resources have been 
already seized at the target access side then the resources shall be released using the Release Termination procedure. 
The call from MSC-A server shall be released as described at clause 7.1. 
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8.1.2.2.8 Example 

Figure 8.3 shows the network model for the Basic Inter-MSC SRNS Relocation. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer control signalling and the bearer. In MGW-A the bearer 
termination Tl is used for the bearer towards RNC-A, bearer termination T3 is used for the bearer towards MGW-B, 
and the bearer termination T2 is used for the bearer towards the succeeding/preceding MGW. In MGW-B the bearer 
termination T4 is used for the bearer towards RNC-B, bearer termination T5 is used for the bearer towards MGW-A. 
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Figure 8.3: Basic Inter-MSC SRNS Relocation (network model) 
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Figure 8.4 shows the message sequence example for the Basic Inter-MSC SRNS Relocation. It is assumed that the 
Handover Device is located in the MGW (MGW-A) selected for the call establishment by the MSG server (MSG-A 
server) which controls the call and the mobility management. It is also assumed that only one bearer has been 
established towards RNG-A. In the example the MSG-B server requests MGW-B to seize an RNG-B side bearer. The 
MSG-B server orders the establishment of the bearer towards RNG-B by sending Relocation Request. The call is 
established between MSG-A and MSG-B servers, and the bearer is estabhshed between MGW-A and MGW-B. When 
the relocation is detected in RNG-B the MSG-A server requests to change the flow directions between the terminations 
within the context in MGW-A. When MSG-A server receives Relocation Gomplete indication from MSG-B server it 
orders RNG-A to release the lU. This action causes release of the bearer between RNG-A and MGW-A. Finally MSG-A 
server requests MGW-A to remove RNG-A side bearer termination. 
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Figure 8.4/1 : Basic inter-IUISC SRNS Relocation (message sequence chart) 
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Figure 8.4/2: Basic Inter-IVISC SRNS Relocation (message sequence chart) 



8.1 .3 Subsequent Inter-MSC SRNS/SBSS Relocation back to the Anchor 
MSG 

The procedures specified in 3GPP TS 23.009 [8] for "Subsequent Relocation from 3G_MSC-B to 3G_MSC-A requiring 
a Circuit Connection between 3G_MSC-A and 3G_MSC-B" shall be followed. The following clauses describe the 
additional requirements for the bearer independent CS core network. 



8.1.3.1 



MSC-A/MGW-A 



8.1.3.1.1 



Relocation Request 



When the MSC-A server receives the MAP Prepare Subsequent Handover request containing a Relocation Request 
message, it requests MGW-A to provide a binding reference and a bearer address using the Prepare Bearer procedure. 
For speech calls, the MSC-A server shall provide the MGW-A with the speech coding information for the bearer. For 
non-speech calls the MSC-A server shall provide MGW-A with the same PLMN Bearer Capability [4] as was provided 
at the last access bearer assignment. The MSC-A server uses the Change Flow Direction procedure to request the 
MGW-A to set the Handover Device to initial state. The MSC-A server sends the Relocation Request message, 
containing the bearer address and the binding reference, to RNC-B (bullet 1 in figure 8.6/1). 

For Relocation towards GERAN lu mode, if the selected service is speech and the MSC-A server cannot provide the 
codec requested by the MSC-B server, the MSC-A server shall select another codec according to the received GERAN 
capabilities of the target cell and the list of supported codecs. 



8.1 .3.1 .2 Relocation Command/Relocation Detect 

When the MSC-A server sends the MAP Prepare Subsequent Handover response message or alternatively if it receives 
the Relocation Detect message, the MSC-A server uses the Change Flow Direction procedure to requests MGW-A to 
set the Handover Device to intermediate state (bullet 2 in figure 8.6/1). 
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8.1 .3.1 .3 Relocation Complete 

When the MSC-A server receives the Relocation Complete message, it informs the MSC-B server about reception of 
this message. The MSC-A server then initiates call clearing towards the MSC-B server as described in clause 7.3. 

8.1.3.1.4 Interworking function 

The interworking function used by MGW-A before relocation will also be used after relocation. 

8.1.3.1.5 Codec handling 

The MOW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.1 .3.1 .6 Voice Processing function 

Voice processing function(s) provided by MGW-A and MGW-B before relocation, may be continued or modified by 
MGW-A after relocation. 

8.1 .3.1 .7 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers all procedures related to the handling of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 

8.1 .3.1 .8 Failure Handling in MSC server 

When a procedure between the MSC-A server and the MOW fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have already been 
seized at the target access side then the resources shall be released using the Release Temiination procedure. If the call 
is to be cleared, then it shall be handled as described in clause 7.3. 

8.1.3.2 MSC-B/MGW-B 

8.1.3.2.1 Relocation Required 

For Relocation towards GERAN lu mode the GERAN capabilities of the target cell will be indicated to the MSC-B 
server within the RANAP RELOCATION REQUIRED message if the target cell provides different capabilities than the 
current cell. If no information about the GERAN capabilities of the target cell are received within this message, the 
MSC-B server shall assume that the GERAN target cell will provide the same capabilities as the current cell (for details 
see [29]). The different interworking scenarios (e.g. interworking to pre-Rel5 UTRAN) are described in [29]. 

The MSC-B server shall indicate to the MSC-A server the GERAN capabilities of the target cell, if available, with the 
MAP Prepare Subsequent Handover request. For speech calls, the MSC-B server shall additionally indicate to the MSC- 
A server the selected codec and the currently used codec. 

Furthermore, the MSC-B server shall indicate to the GERAN the selected service within the RANAP RELOCATION 
REQUEST message and shall set the RAB parameters within the RANAP RELOCATION REQUEST 
message according to the selected service. The MSC server shall not set codec information in the NAS Synchronisation 
Indicator (see [4]). Instead it shall set codec information in the GERAN BSC container... 

8.1.3.2.2 Relocation Complete 

When the MSC-B server receives the Relocation Complete message, it requests RNC-A to release the lU. The MSC-B 
server requests MGW-B to remove the bearer termination towards RNC-A using the Release Termination procedure 
(bullet 3 in figure 8.6/2). 

8.1 .3.2.3 Release of bearer towards MGW-A 

When the MSC-B server receives a call clearing indication from the MSC-A server, the MSC-B server handles it as 
described in clause 7.2. 
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8.1 .3.2.4 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers all procedures related to the handling of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 



8.1.3.2.5 



Example 



Figure 8.5 shows the network model for the Subsequent Inter-MSC SRNS Relocation back to the Anchor MSC. The 
"squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling and the 
bearer. In MGW-A the bearer termination T6 is used for the bearer towards RNC-B, bearer termination T3 is used for 
the bearer towards MGW-B, and the bearer termination T2 is used for the bearer towards the succeeding/preceding 
MGW. In MGW-B the bearer termination T4 is used for the bearer towards RNC-A, bearer termination T5 is used for 
the bearer towards MGW-A. 



^ RNCA ^ 



MSC-S B 






r \ 

MSC-S A 






Before Relocation: 




During Relocation: 




^ y 



After Relocation: 



Figure 8.5: Subsequent Inter-MSC SRNS Relocation back to the Anchor MSC (network model) 
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Figure 8.6 shows the message sequence example for the Subsequent Inter-MSC SRNS Relocation back to the Anchor 
MSC. It is assumed that the Handover Device is located in the MGW (MGW-A) selected for the call establishment by 
the MSC server (MSC-A server) which controls the call and the mobility management. Also assumed that only one 
bearer has been established towards RNC-A. In the example the MSC-A server requests MGW-A to seize RNC-B side 
bearer termination with specific flow directions. The MSC server orders the establishment of the bearer towards RNC-B 
by sending Relocation Request. When the relocation is detected in RNC-B the MSC-A server requests to change the 
flow directions between the terminations within the context in MGW-A. When the MSC-A server receives a Relocation 
Complete indication from RNC-B it transfers this indication to MSC-B server. MSC-B server orders RNC-A to release 
the lU. This action causes release of the bearer between RNC-A and the MGW-B. MSC-A server initiates call clearing 
towards MSC-B server. 
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Figure 8.6/1 : Subsequent Inter-MSC SRNS Relocation back to the Anchor MSC 

(message sequence chart) 
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Figure 8.6/2: Subsequent Inter-MSC SRNS Relocation back to the Anchor MSC 

(message sequence chart) 

8.1 .4 Subsequent Inter-MSC SRNS/SBSS Relocation to a third MSC 

The relocation to a third MSC server (from MSC-B server to MSC-B server) is the combination of the two previous 
inter-MSC handover cases: 

for MSC-B server a subsequent relocation from MSC-B server back to MSC-A server as described in clause 
8.1.3; and 

for MSC-B server a basic relocation from MSC-A server to MSC-B server as described in clause 8. 1 .2. 

MSC-A server implements the corresponding parts of each handover case; i.e. access handling in MSC-A server is not 
included. 



8.1 .5 SRNS/SBSS Relocation with lu on IP 

If luCS on IP is supported by the MSC server, the Core Network side procedures described in 8.1.1, 8.1.2, 8.1.3 and 
8. 1 .4 shall apply. For the access bearer termination, the exchange of IP addresses via call control procedures is 
described in this clause. 

Before the MSC server starts the access bearer assignment, the MSC server requests the MGW to prepare for the access 
bearer using the Prepare_IP_Transport procedure. The MSC server requests the MGW to provide an IP Transport 
address and UDP Port and provides the MGW with the bearer characteristics. For speech calls, the MSC server shall 
provide the MGW with the speech coding information and conditionally GTT related information in accordance with 
3GPP TS 23.226 [28] for the bearer. For a non-speech call the MSC server also provides the MGW with a PLMN 
Bearer Capability [4]. After the MGW has replied with the IP address and UDP Port the MSC server requests access 
bearer assignment using the provided IP address and UDP Port in accordance with 3GPP TS 25.413 [26]. The IP 
addresses and UDP Ports of the MGW and the RNC are exchanged via the RANAP procedures. If the bearer transport 
is IP and luUP mode is Transparent, when the MSC receives the RANAP lu Relocation Request response, it shall send 
the RNC IP address and UDP Port to the MGW Access bearer termination using the Modify_IP_Transport_Address 
procedure. 

If the bearer transport is IP and luUP mode is Support, the MGW shall use the source IP address and UDP Port of the 
luUP Init packet received from the radio access network as the destination address for subsequent downlink packets. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 

The sequence is shown in figure 8.1.5/1. 



76 



ETSI TS 123 205 V9.2.0 (2011-04) 



RNC A 




MSC-S 




MGW 




RNCB 



For preceeding signalling sequences for establishing core network bearer see 
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Figure 8.1.5/1 SRNS Relocation with lu on IP 



8.1 .6 Intra-MSC enhanced SRNS Relocation 



8.1.6.1 Introduction 

The procedures specified in 3GPP TS 23.009 [8] for "Intra-3G_MSC SRNS Relocation" shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. The support of the 
enhanced SRNS Relocation is optional. 



8.1 .6.2 Enhanced Relocation Complete Request 

When the Enhanced Relocation Complete Request message is received, the MSG server requests the MGW to provide a 
binding reference and a bearer address, using the Prepare Bearer procedure. For speech calls, the MSG server shall 
provide the MGW with the speech coding information for the bearer. For non-speech calls the MSG server also 
provides the MGW with the same PLMN Bearer Gapability [4] as was provided at the last access bearer assignment. 
The MSG server uses the Ghange Flow Direction Procedure to request the MGW to set the Handover Device to initial 
state. If required the MSG Server shall set-up an interconnection between the "anchor" and the "target" MGW. The 
MSG server then sends the Enhanced Relocation Complete Response message, containing the bearer address and the 
binding reference, to RNG-B (bullet 1 in figure 8.1.6/2). 
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8.1 .6.3 Enhanced Relocation Complete Confirm 

When the MSC server receives the Enhanced Relocation Complete Confirm message, the MSC server uses the Change 
Flow Direction procedure to request the MGW to set the Handover Device to intermediate state (buUet 2 in figure 
8.1.6/1). 

After that the MSC Server requests RNC-A to release the lU. The MSC server also requests the MGW to set the 
Handover Device to its final state by removing the bearer termination towards RNC-A, using the Release Termination 
procedure (buUet 3 in figure 8.1.6/2). 

8.1 .6.4 Inten/vorking function 

The interworking function used by the MGW before relocation will also be used after relocation. 

8.1 .6.5 Codec handling 

The MGW may include a speech transcoder based upon the speech coding irrformation provided to each bearer 
termination. 

8.1 .6.6 Voice Processing function 

After relocation, the MGW may continue or modify voice-processing function(s) provided to each bearer termination. 

8.1 .6.7 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers all procedures related to the handUng of bearers and terminations described 
for the relocation of a single bearer shall be repeated for each bearer. 

8.1 .6.8 Failure Handling in MSC server 

When a procedure between the MSC server and the MGW fails the MSC server shall send an lU-ENHANCED- 
RELOCATION-COMPLETE-FAILURE message to RNS-B in accordance with 3GPP TS 23.009 [8] and 3GPP TS 
29.010 [23]. If MGW resources have been already seized at the target access side then the resources shall be released 
using the Release Termination procedure. If the call is to be cleared, then it shall be handled as described in clause 7.3. 

8.1.6.9 Example 

Figure 8.1.6/1 shows the network model for the Intra-MSC enhanced SRNS Relocation. The "squared" line represents 
the call control signalling. The "dotted" line represents the bearer control signalling and the bearer. The bearer 
termination Tl is used for the bearer towards RNC-A, bearer termination T3 is used for the bearer towards RNC-B and 
the bearer termination T2 is used for the bearer towards the succeeding/preceding MGW. 
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V J 

Before Relocation: 




After Relocation: 




V J 



After release of Source side resources: 

Figure 8.1.6/1 : Intra-MSC Enhanced SRNS Relocation (network model) 

Figure 8.1.6/2 shows the message sequence example for the Intra-MSC enhanced SRNS Relocation. 
It is assumed that the Handover Device is located in the MGW, which has been selected for the call establishment by 
the MSC server. The MSC server controls the call and the mobility management. It is also assumed that only one bearer 
has been established towards RNC-A. 

In the example the MSC server requests seizure of RNC-B side bearer termination with specific flow directions. The 
MSC server orders the establishment of the bearer by sending Enhanced Relocation Complete Response towards RNC- 
B. When the MSC server receives an Enhanced Relocation Complete Confirm indication from RNC-B the MSC server 
requests to change the flow directions between the terminations within the context. MSC Server also orders RNC-A to 
release the lU. This action causes release of the bearer between the RNC-A and the MGW. Finally the MSC server 
requests the MGW to release RNC-A side bearer termination. 
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Figure 8.1.6/2: Intra-MSC Enhanced SRNS Relocation (message sequence chart) 

8.1 .7 Intra-MSC enhanced SRNS Relocation with lu on IP 

If luCS on IP is supported by the MSG server, the Core Network side procedures described in 8.1.x shall apply. For the 
access bearer termination, the exchange of IP addresses via call control procedures as described in 8.1.5 applies with the 
following exception. The Prepare_IP_Transport procedure is used after the MSG Server receives the RANAP Enhanced 
Relocation Complete Request. If the bearer transport is IP and luUP mode is Transparent, when the MSC Server 
receives the RANAP Enhanced Relocation Complete Response, it shall send the RNC IP address and UDP Port to the 
MGW Access bearer termination using the Modify_IP_Transport_Address procedure. 



The sequence is shown in figure 8.7/1. 
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Figure 8.1.7/1 Enhanced SRNS Relocation with lu on IP 



8.2 



UMTS to GSM 



In the context of the following clauses, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an UE in lu mode. 

8.2.1 Intra-MSC UMTS to GSM Handover 

The procedures specified in 3GPP TS 23.009 [8] for "Inti-a-3G_MSC Handover from UMTS to GSM" shall be 
followed. The following clauses describe the additional requirements for the bearer independent CS core network. 



8.2.1.1 



Relocation Required 



When the MSC server receives the Relocation Required message, it requests the MGW to seize a TDM circuit, using 
the Reserve Circuit procedure. For non-speech calls the MSC server shall provide the MGW with the GSM Channel 
coding properties and the same PLMN Bearer Capability [4] as was provided at the last access bearer assignment. The 
MSC server uses the Change Flow Direction procedure to request the MGW to set the Handover Device to initial state. 
The MSC server sends the Handover Request message, containing the CIC, to BSC-B (bullet 1 in figure 8.8/1). 
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8.2.1 .2 Handover Request Acknowledge 

For non-speech calls after receiving the Handover Request Acknowledge message if the assigned GSM Channel coding 
properties differ from the previously provided ones the MSG server provides the MGW with the assigned GSM Ghannel 
coding properties using the Modify Bearer Characteristics procedure (bullet 2 in figure 8.8/1). 

8.2.1 .3 Relocation Command/Handover Detect 

When the MSC server sends the Relocation Command message or alternatively if it receives the Handover Detect 
message, the MSC server uses the Change Flow Direction procedure to requests the MGW to set the Handover Device 
to intermediate state (bullet 3 in figure 8.8/1). 

8.2.1 .4 Handover Complete 

When the MSC server receives the Handover Complete message, it requests RNC-A to release the lU. The MSC server 
also requests the MGW to set the Handover Device to its final state by removing the bearer termination towards 
RNC-A, using the Release Termination procedure (bullet 4 in figure 8.8/2). 

8.2.1 .5 Inten/vorking function 

The interworking function used by the MGW before handover will also be used after handover. 

8.2.1 .6 Voice Processing function 

After handover, the MGW may continue or modify voice processing function(s) provided to each bearer termination. 

8.2.1 .7 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers then one bearer is selected to be handed over according to 3GPP TS 23.009 
[8]. The calls carried by the bearers that have not been selected will be cleared after the reception of the Handover 
Complete message, as described in clause 7.3. 

8.2.1 .8 Failure Handling in MSC server 

When a procedure between the MSC server and the MGW fails the MSC server shall handle the failure as an internal 
error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have been already seized at 
the target access side then the resources shall be released using the Release Termination procedure. If the call is to be 
cleared, then it shall be handled as described in clause 7.3. 

8.2.1.9 Example 

Figure 8.7 shows the network model for the Intra-MSC UMTS to GSM Handover. The "squared" line represents the 
call control signalling. The "dotted" line represents the bearer control signalling (not applicable in case of GSM access) 
and the bearer. The bearer termination Tl is used for the bearer towards RNC-A, bearer termination T3 is used for the 
bearer towards BSC-B and the bearer termination T2 is used for the bearer towards the succeeding/preceding MGW. 
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During Handover 
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After Handover 

Figure 8.7: Intra-IVISC UIVITS to GSIV! Handover (networl< model) 

Figure 8.8 shows the message sequence example for the Intra-MSC UMTS to GSM Handover. 
It is assumed that the Handover Device is located in the MGW selected for the call establishment by the MSG server, 
which controls the call and the mobility management. It is also assumed that only one bearer has been established 
towards RNC-A and that MGW-A is capable of handUng GSM access. 

In the example the MSG server requests seizure of BSG-B side bearer termination with specific flow directions. The 
MSG server starts handover execution by sending Handover Request towards BSG-B. When the handover is detected in 
BSG-B the MSG server requests to change the flow directions between the terminations within the context. When MSG 
server receives Handover Gomplete indication from BSG-B it orders RNG-A to release the lU. Finally the MSG server 
requests the MGW to release RNG-A side bearer termination. 
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Figure 8.8/1 : Intra-MSC UMTS to GSM Handover (message sequence chart) 
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Figure 8.8/2: Intra-MSC UMTS to GSM Handover (message sequence chart) 



Intra-MSC UMTS to GSM Handover for A interface over IP 



When the MSG server receives the RANAP Relocation Required message, it requests the MGW to reserve an RTP 
bearer termination using the Reserve RTP Connection Point procedure. The MSG server requests the MGW to reserve 
an IP address and UDP port. The MSG server uses the Ghange Flow Direction procedure to request the MGW to set the 
Handover Device to initial state. 

The MGW reserves the RTP termination and indicates the IP address and UDP port number to the MSG server. The IP 
addresses and UDP ports of the MGW is sent to the BSG in the BSSMAP Handover Request message. When the MSG 
server receives the BSSMAP Handover Request- Ack message, it shall send the BSG IP address and UDP Port number 
to the MGW using the Gonfigure RTP Gonnection Point procedure. 



The sequence is shown in Figure 8.2.1.10/1. 
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Figure 8.2.1.10/1 : Intra-MSC UMTS to GSM Handover for AolP (message sequence chart) 

8.2.2 Basic Inter-MSC UMTS to GSM Handover 

The procedures specified in 3GPP TS 23.009 [8] for "Basic Handover Procedure Requiring a Circuit Connection 
between 3G_MSC-A and MSC-B" shaU be followed. The following clauses describe the additional requirements for the 
bearer independent CS core network. 

8.2.2.1 MSC-A/MGW-A 

8.2.2.1 .1 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment between MGW-A and MGW-B is as described for a Basic Mobile Originating 
Call, using either forward or backward bearer establishment. For non-speech calls the MSC-A server shall provide 
MGW-A with the GSM Channel coding properties and the same PLMN Bearer Capability [4] as was provided at the 
last access bearer assignment. The MSC-A server also uses the Change Flow Direction procedure to request MGW-A to 
set the Handover Device to initial state (bullet 3 in figure 8.10/1). 



8.2.2.1.2 



Relocation Command/Handover Detect 



When the MSC-A server sends the Relocation Command message or altematively if it receives the Handover Detect 
message, the MSC-A server uses the Change Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state (buUet 2 in figure 8.10/1). 
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8.2.2.1.3 Handover Complete 

When the MSC-A server receives the Relocation Complete message, it requests RNC-A to release the lU. The MSC-A 
also requests the MGW to set the Handover Device to its final state by removing the bearer termination towards 
RNC-A, using the Release Termination procedure (bullet 3 in figure 8.10/1). 

8.2.2.1.4 Interworking function 

The interworking function used by MGW-A before handover will also be used after handover. 

8.2.2.1 .5 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be continued or modified by MGW-A and/or 
MGW-B after handover. 

8.2.2.1 .6 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers then one bearer is selected to be handed over according to 3GPP TS 23.009 
[8]. The calls carried by bearers that have not been selected will be cleared after the reception of Handover Complete 
message, as described in clause 7.3. 

8.2.2.1 .7 Failure Handling in MSG server 

When a procedure between the MSC-A server and MGW-A fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-A resources have been 
already seized for the bearer towards MGW-B then the resources shall be released using the Release Termination 
procedure. The call towards MSC-B server shall be cleared as described in clause 7.3. If the original call is to be 
cleared, then it shall be handled as described in clause 7.3. 



8.2.2.2 MSC-B/MGW-B 

8.2.2.2.1 MGW selection 

The MSC-B server selects an MGW when it receives Prepare Handover Request message (bullet 1 in figure 8.10/1). 

8.2.2.2.2 Bearer establishment towards BSC-B 

When the MSC-B server has selected MGW-B it requests MGW-B to seize a TDM circuit, using the Reserve Circuit 
procedure. The MSC-B server sends the Handover Request message to the BSC-B containing the CIC (bullet 2 in 
figure 8.10/1). 

8.2.2.2.3 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment between MGW-A and MGW-B is as described for a Basic Mobile 
Terminating Call, using either forward or backward bearer establishment. 

8.2.2.2.4 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be continued or modified by MGW-B after 
handover. 

8.2.2.2.5 Failure Handling in MSG server 

When a procedure between the MSC-B server and MGW-B fails the MSC-B server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-B resources have already 
been seized at the target access side then the resources shall be released using the Release Termination procedure. The 
call ftom MSC-A server shall be released as described at subclause 7.1. 
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8.2.2.2.6 



Example 



Figure 8.9 shows the network model for the Basic Inter-MSC UMTS to GSM Handover. The "squared" hne represents 
the call control signalling. The "dotted" line represents the bearer control signalling (not applicable in case of GSM 
access) and the bearer. In MGW-A the bearer termination Tl is used for the bearer towards RNC-A, bearer termination 
T3 is used for the bearer towards MGW-B, and the bearer termination T2 is used for the bearer towards the 
succeeding/preceding MGW. In MGW-B the bearer termination T4 is used for the bearer towards BSC-B, bearer 
termination T5 is used for the bearer towards MGW-A. 
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Figure 8.9: Basic Inter-IUISC UIVITS to GSIV! Handover (networl< model) 
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Figure 8.10 shows the message sequence example for the Basic Inter-MSC UMTS to GSM Handover. 
It is assumed that the Handover Device is located in the MGW (MOW- A) which has been selected for the call 
establishment by the MSG server (MSG-A server). The MSG server controls the call and the mobility management. It is 
also assumed that only one bearer has been established towards RNG-A. 

In the example the MSG-B server requests MGW-B to seize BSG-B side bearer termination. The call is established 
between MSG-A server and MSG-B server, and the bearer is established between MGW- A and MGW-B. When the 
handover is detected in BSG-B the MSG-A server requests to change the flow directions between the terminations 
within the context in MGW- A. When MSG-A server receives Handover Gomplete indication from MSG-B server it 
orders RNG-A to release the lU. Finally MSG-A server requests MGW-A to remove RNG-A side bearer termination. 
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Figure 8.10/1 : Basic Inter-IUISC UlUITS to GSIU! Handover (message sequence chart) 
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Figure 8.10/2: Basic Inter-MSC UMTS to GSM l-landover (message sequence chiart) 



8.2.2.3 



Basic Inter-MSC UMTS to GSM Handover for A Interface over IP 



If AoIP is supported by the MSC server, the Core Network side procedures described earlier in 8.2.2 shall apply. For 
the access side termination, the exchange of IP addresses via call control procedures is described in this clause. 

When the MSC-B server receives the MAP Prepare Handover Request., it requests the MGW-B to reserve an RTP 
bearer termination using the Reserve RTP Connection Point procedure. The MSC-B server requests the MGW-B to 
reserve an IP address and UDP port. 

The MGW-B reserves the RTP termination and indicates the IP address and UDP port number to the MSC-B server. 
The IP addresses and UDP ports of the MGW is sent to the BSC-B in the BSSMAP Handover Request message. When 
the MSC-B server receives the BSSMAP Handover Request- Ack message, it shall send the BSC-B IP address and UDP 
Port number to the MGW-B using the Configure RTP Connection Point procedure. 
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Figure 8.2.2.3/1 : Basic Inter-MSC UlUlTS to GSIUl IHandover for AolP (message sequence cliart) 



8.2.3 Subsequent Inter-IVISC UIVITS to GSIVI Handover back to tlie Anclior 
IVISC 

The following handling shall be applied for a call that started as UMTS call. The procedures specified in 
3GPP TS 23.009 [8] for "Subsequent UMTS to GSM handover requiring a Circuit Connection between 3G_MSC-A 
and 3G_MSC-B, 3G_MSC-B to MSC-A" shall be followed. The following clauses describe the additional requirements 
for the bearer independent CS core network. 

8.2.3.1 MSC-A 

8.2.3.1 .1 Handover Request 

When the MSC-A server receives the MAP Prepare Subsequent Handover request containing a Handover Request 
message , it requests MGW-A to seize a TDM circuit, using the Reserve Circuit procedure. For non-speech calls the 
MSC-A server shall provide MGW-A with the GSM Channel coding properties and the same PLMN Bearer Capability 
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[4] as was provided at the first access bearer assignment. The MSC-A server uses the Change Flow Direction procedure 
to request MGW-A to set the Handover Device to initial state. The MSC-A server sends the Handover Request 
message, containing the CIC, to BSC-B (bullet 1 in figure 8.12/1). 

8.2.3.1 .2 Handover Request Acknowledge 

For non-speech calls after receiving the Handover Request Acknowledge message if the assigned GSM Channel coding 
properties differ from the previously provided ones the MSC-A server shall provide MGW-A with the assigned GSM 
Channel coding properties using the Modify Bearer Characteristics procedure (bullet 2 in figure 8.12/1). 

8.2.3.1 .3 Relocation Command/Handover Detect 

When the MSC-A server sends the MAP Prepare Subsequent Handover response message or alternatively if it receives 
the Handover Detect message, the MSC-A server uses the Change Flow Direction procedure to requests MGW-A to set 
the Handover Device to intermediate state (bullet 3 in figure 8.12/2). 

8.2.3.1.4 Handover Complete 

When the MSC-A server receives the Handover Complete message, it informs the MSC-B server about reception of this 
message (bullet 3 in figure 8.12/2). The MSC-A server then initiates call clearing towards the MSC-B server as 
described at 7.3. 

8.2.3.1 .5 Interworking function 

The interworking function used by MGW-A before handover will also be used after handover. 

8.2.3.1 .6 Voice Processing function 

Voice processing function(s) provided by MGW-A and MGW-B before handover, may be continued or modified by 
MGW-A after handover. 

8.2.3.1 .7 Handling of multiple bearers (multicall) 

If the UE is engaged with multiple bearers the selected bearer to be handed over is received from MSC-B server in the 
Handover Request message according to 3GPP TS 23.009 [8]. The calls carried by the bearers that have not been 
selected will be cleared by MSC-A server after the reception of the Handover Complete message, as described in 
clause 7.3. 

8.2.3.1 .8 Failure Handling in MSG server 

When a procedure between the MSC-A server and the MGW fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have already been 
seized at the target access side then the resources shall be released using the Release Termination procedure. If the call 
is to be cleared, then it shall be handled as described in clause 7.3. 

8.2.3.2 MSC-B 

8.2.3.2.1 Handover Complete 

When the MSC-B server receives the Handover Complete message, it requests RNC-A to release the lU. The MSC-B 
server also requests MGW-B to remove the bearer termination towards RNC-A using the Release Termination 
procedure (bullet 4 in figure 8.12/2). 

8.2.3.2.2 Release of bearer towards MGW-A 

When the MSC-B server receives a call clearing indication from the MSC-A server, the MSC-B server handles it as 
described in clause 7.2. 
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8.2.3.2.3 Handling of multiple bearers (multicall) 

If the UE is engaged with muhiple bearers then one bearer is selected by MSC-B server to be handed over according to 
3GPP TS 23.009 [8]. 

8.2.3.2.4 Example 

Figure 8.1 1 shows the network model for the Subsequent Inter-MSC UMTS to GSM handover back to the Anchor 
MSG. The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling 
(not applicable in case of GSM access) and the bearer. In MGW-A the bearer termination T6 is used for the bearer 
towards BSC-B, bearer termination T3 is used for the bearer towards MGW-B, and the bearer termination T2 is used for 
the bearer towards the succeeding/preceding MGW. In MGW-B the bearer termination T4 is used for the bearer 
towards RNC-A, bearer termination T5 is used for the bearer towards MGW-A. 
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Figure 8.11 : Subsequent Inter-MSC UMTS to GSM Handover back to the Anchor MSG 

(network model) 

Figure 8.12 shows the message sequence example for the Subsequent Inter-MSC UMTS to GSM Handover back to the 
Anchor MSC. It is assumed that the Handover Device is located in the MGW (MGW-A) selected for the call 
establishment by the MSC server (MSC-A server) which controls the call and the mobility management. Also assumed 
that only one bearer has been established towards RNC-A and that MGW-A is capable to handle GSM access. In the 
example the MSC-A server requests MGW-A to seize BSC-B side bearer termination with specific flow directions. 
When the relocation is detected in BSC-B the MSC-A server requests to change the flow directions between the 
terminations within the context in MGW-A. When MSC-A server receives Handover Complete indication from BSC-B 
it transfers this indication to MSC-B server. MSC-B server orders RNC-A to release the lU. MSC-A server initiates call 
clearing towards MSC-B server. 
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Figure 8.12/1 : Subsequent Inter-MSC UMTS to GSM Handover back to the Anchor MSC 

(message sequence chart) 
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Figure 8.12/2: Subsequent Inter-MSC UMTS to GSM Handover back to the Anchor MSC 

(message sequence chart) 



8.2.3.3 Subsequent Inter-MSC UMTS to GSM Handover back to the anchor MSC for 
A Interface over IP 

When the MSC-A server receives the MAP Prepare Subsequent Handover Request, message, it requests the MGW-A to 
reserve an RTP bearer termination using the Reserve RTP Connection Point procedure. The MSC-A server requests the 
MGW-A to reserve an IP address and UDP port. The MSC-A server uses the Change Flow Direction procedure to 
request the MGW-A to set the Handover Device to initial state. 
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The MGW-A reserves the RTP termination and indicates the IP address and UDP port number to the MSC-A server. 
The IP addresses and UDP ports of the MGW-A is sent to the BSC-B in the BSSMAP Handover Request message. 
When the MSC-A server receives the BSSMAP Handover Request- Ack message, it shall send the BSC-A IP address 
and UDP Port number to the MGW-B using the Configure RTP Connection Point procedure. 

The sequence is shown in Figure 8.2.3.3/1. 
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Figure 8.2.3.C.1 : Subsequent Inter-MSC UMTS to GSM Handover back to the anchor MSG for AolP 

(message sequence chart) 

8.2.4 Subsequent Inter-MSC UMTS to GSM Handover to a third MSG 

The UMTS to GSM handover to a third MSC server (from MSC-B server to MSC-B server) is the combination of the 
two previous inter-MSC handover cases: 

- for MSC-B server a subsequent UMTS to GSM handover from MSC-B server back to MSC-A server as 
described in clause 8.2.3; and 

- for MSC-B server a basic UMTS to GSM handover from MSC-A server to MSC-B server as described in 
clause 8.2.2. 

MSC-A server implements the corresponding parts of each handover case; i.e. access handling in MSC-A server is not 
included. 



8.3 GSM to UMTS 



In the context of the following clauses, the terms RNS or RNC refer also to a GERAN BSS or BSC (respectively) when 
serving an UE in lu mode. 
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8.3.1 Intra-MSC GSM to UMTS Handover 

The procedures specified in 3GPP TS 23.009 [8] for "Intra-3G_MSC GSM to UMTS Handover" shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. 

8.3.1.1 Handover Required 

When the MSG server receives the Handover Required message, it requests the MGW to provide a binding reference 
and a bearer address using the Prepare Bearer procedure. For speech calls, the MSG server shall provide the MGW with 
the speech coding information for the bearer. For non-speech calls the MSG server shall provide the MGW with the 
same PLMN Bearer Gapability [4] as was provided at the last channel assignment. The MSG server uses the Ghange 
Flow Direction procedure to request the MGW to set the Handover Device to initial state. The MSG server sends the 
Relocation Request message to the RNG-B containing the bearer address and binding reference (bullet 1 in figure 8.14). 

For Relocation towards GERAN lu mode the GERAN capabilities of the target cell will be indicated to the MSG-Server 
within the Handover Required message if the target cell provides different capabihties than the current cell. If no 
information about the GERAN capabilities of the target cell are received within this message, the MSG-Server shall 
assume that the GERAN target cell will provide the same capabilities as the current cell (for details see [29]). The MSG 
server shall indicate to GERAN the selected services within the RANAP RELOGATION REQUEST message. The 
MSG server shall not set codec information in the NAS Synchronisation Indicator (see [4]). Instead it shall set codec 
information in the GERAN BSG container. 

8.3.1 .2 Handover Command/Relocation Detect 

When the MSG server sends the Handover Gommand message or alternatively if it receives a Relocation Detect 
message, the MSG server uses the Ghange Flow Direction procedure to requests the MGW to set the Handover Device 
to intermediate state (bullet 2 in figure 8.14). 

8.3.1.3 Relocation Complete 

When the MSG server receives the Relocation Gomplete message, it releases the A-interface line towards BSG-A and 
requests the MGW to set the Handover Device to its final state removing the bearer termination towards BSG-A, using 
Release Termination procedure (bullet 3 in figure 8.14). 

8.3.1.4 Interworking function 

The interworking function used by the MGW before handover will also be used after handover. 

8.3.1 .5 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.3.1 .6 Voice Processing function 

After handover, the MGW may continue or modify voice processing function(s) provided to each bearer termination. 

8.3.1 .7 Failure Handling in MSC server 

When a procedure between the MSG server and the MGW fails the MSG server shall handle the failure as an internal 
error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have already been seized at 
the target access side then the resources shall be released using the Release Termination procedure. If the call is to be 
cleared, then it shall be handled as described in clause 7.3. 

8.3.1.8 Example 

Figure 8.13 shows the network model for the Intra-3G_MSG GSM to UMTS Handover. The "squared" hne represents 
the call control signalhng. The "dotted" hne represents the bearer control signalling and the bearer. The bearer 
termination Tl is used for the bearer towards the BSG-A (connected through the MSG server), the bearer termination 
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T3 is used for the bearer towards the RNC-B and the bearer termination T2 is used for the bearer towards the 
succeeding/preceding MGW. 




MGW 
V J 



Before Handover 




During Handover 




After Handover 

Figure 8.13: lntra-3G_l\/!SC GSIV! to UIVITS Handover (networl< model) 

Figure 8.14 shows the message sequence example for the Intra-MSC GSM to UMTS Handover. 
It is assumed that the Handover Device is located in the MGW selected for the call establishment by the MSG server, 
which controls the call and the mobility management. In the example the MSG server requests seizure of RNG-B side 
bearer termination with specific flow directions. The MSG server starts handover execution by sending Relocation 
Request towards RNG-B. When the relocation is detected in RNG-B the MSG server requests to change the flow 
directions between the terminations within the context. When MSG server receives Relocation Gomplete indication 
from RNG-B it releases the A-interface line towards the BSG-A. Finally the MSG server requests the MGW to release 
BSG-A side bearer termination. 
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Figure 8.14: lntra-3G_MSC GSM to UMTS Handover (message sequence chart) 

8.3.2 Basic Inter-MSC GSM to UMTS Hancdover 

The following handling shall be applied for a call that started as UMTS call. The procedures specified in 

3GPP TS 23.009 [8] for "Basic Handover Procedure Requiring a Circuit Connection between MSC-A and 3G_MSC-B" 

shall be followed. The following clauses describe the additional requirements for the bearer independent CS core 

network. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



99 



ETSI TS 123 205 V9.2.0 (2011-04) 



8.3.2.1 MSC-A 

8.3.2.1.1 Handover Required 

For Handover towards GERAN lu mode the GERAN capabilities of the target cell will be indicated to the MSC-A 
server within the Handover Required message if the target cell provides different capabiUties than the current cell. If no 

information about the GERAN capabilities of the target cell are received within this message, the MSC-A server shall 
assume that the GERAN target cell will provide the same capabilities as the current cell (for details see [29]). 

The MSC-A server shall indicate to the MSC-B server the GERAN capabilities of the target cell, if available, with the 
MAP Prepare Handover request. For speech calls, the MSC-A server shall additionally indicate to the MSC-B server the 
selected codec, the Ust of supported codecs, and the currently used codec. 

8.3.2.1 .2 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment between MGW-A and MGW-B is as described for a Basic Mobile Originating 
Call, using either forward or backward bearer estabUshment. For speech calls, the MSC-A server shall provide the 
MGW-A with the speech coding information for the bearer. For non-speech calls the MSC-A server shall provide 
MGW-A with the same PLMN Bearer Capabilities [4] as were provided at the last access bearer assignment. The 
MSC-A server also uses the Change Flow Direction procedure to request MGW-A to set the Handover Device to initial 
state (bullet 3 in figure 8.16/1). 

8.3.2.1 .3 Handover Command/Handover Detect 

When the MSC-A server sends the Handover Command message or alternatively if it receives the Handover Detect 
message, the MSC-A server uses the Change Flow Direction procedure to requests MGW-A to set the Handover Device 
to intermediate state (bullet 4 in figure 8.16/2). 

8.3.2.1.4 Handover Complete 

When the MSC-A server receives the Handover Complete message, it releases the A-interface line towards BSC-A and 
requests MGW-A to set the Handover Device to its final state by removing the bearer termination towards BSC-A, 
using Release Termination procedure (bullet 5 in figure 8.16/2). 

8.3.2.1.5 Interworking function 

The interworking function used by MGW-A before handover will also be used after handover. 

8.3.2.1.6 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.3.2.1 .7 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be modified or disabled by MGW-A after 
handover. 
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8.3.2.1 .8 Failure Handling in MSG server 

When a procedure between the MSC-A server and MGW-A fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If the call establishment towards 
MSC-B has already started then the call towards MSC-B server shall be cleared as described in clause 7.3. If the 
original call is to be cleared, then it shall be handled as described in clause 7.3. 

8.3.2.2 MSC-B 

8.3.2.2.1 MGW selection 

The MSC-B server selects an MGW when it receives Prepare Handover Request message (bullet 1 in figure 8.16). 

8.3.2.2.2 Bearer establishment towards RNC-B 

When the MSC-B server has selected MGW-B it requests MGW-B to provide a binding reference and a bearer address 
using the Prepare Bearer procedure. For speech calls, the MSC server shall provide the MGW with the speech coding 
iirformation for the bearer. The MSC-B server sends the Relocation Request message to the RNC-B containing the 
bearer address and binding reference (bullet 2 in figure 8.16). 

For Handover towards GERAN lu-mode, the MSC-B Server shall select a service according to the Channel Type 
received with the Handover Request message and the capabilities of the GERAN target cell, if the GERAN classmark 
was received. For speech calls, the MSC-B server shall additionally take into account the selected codec, the list of 
supported codecs and the currently used codec received with MAP Prepare Handover request. The list of permitted 
speech versions received with the Channel Type in the Handover Request message is applicable to GERAN A/Gb mode 
only. 

The MSC-B server shall indicate to the GERAN the selected service within the RANAP RELOCATION REQUEST 
message and shall set the RAB parameters within the RANAP RELOCATION REQUEST message according to the 
selected service. The MSC server shall not set codec information in the NAS Synchronisation Indicator (see [4]). 
Instead it shall set codec iirformation in the GERAN BSC container.. 

For speech calls, the MSC-B server shall report the chosen codec and codec modes back to the MSC-A server with 
MAP Prepare Handover response. 

8.3.2.2.3 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment is as described at Basic Mobile Terminating Call, using either forward or 
backward bearer estabUshment. 

8.3.2.2.4 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.3.2.2.5 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be continued or modified by MGW-B after 
handover. 

8.3.2.2.6 Failure Handling in MSC server 

When a procedure between the MSC-B server and MGW-B fails the MSC-B server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-B resources have already 
been seized at the target access side then the resources shall be released using the Release Termination procedure. The 
call from MSC-A server shall be released as described at clause 7.1. 
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8.3.2.2.7 Example 

Figure 8.15 shows the network model for the Basic Inter-MSC GSM to UMTS Handover. The "squared" line represents 
the call control signalling. The "dotted" line represents the bearer control signalling (not applicable in case of GSM 
access) and the bearer. In MGW-A the bearer termination Tl is used for the bearer towards BSC-A, bearer termination 
T3 is used for the bearer towards MGW-B, and the bearer termination T2 is used for the bearer towards the 
succeeding/preceding MGW. In MGW-B the bearer termination T4 is used for the bearer towards RNC-B, bearer 
termination T5 is used for the bearer towards MGW-A. 




Before Handover 




Figure 8.15: Basic Inter-IVISC GSIV! to UIVITS Handover (networl< model) 

Figure 8.16 shows the message sequence example for the Basic Inter-MSC GSM to UMTS Handover. 

It is assumed that the Handover Device is located in the MGW (MGW-A) selected for the call establishment by the 

MSG server (MSC-A server) which controls the call and the mobility management. 
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In the example the MSC-B server requests MGW-B to seize RNC-B side bearer termination. The call is established 
between MSG- A server and MSC-B server, and the bearer is established between MGW-A and MGW-B. When the 
relocation is detected in RNC-B the MSC-A server requests to change the flow directions between the terminations 
within the context in MGW-A. When MSC-A server receives Handover Complete indication from MSC-B server it 
releases the A-interface line towards the BSC-A. Finally MSC-A server requests MGW-A to remove BSC-A side bearer 
termination. 
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Figure 8.16/1 : Basic Inter-MSC GSM to UMTS Handover (message sequence chart) 
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Figure 8.16/2: Basic Inter-MSC GSM to UMTS Handover (message sequence chart) 

8.3.3 Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor 
MSG 

The following handling shall be appUed for a call that started as UMTS call. The procedures specified in 

3GPP TS 23.009 [8] for "Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSG" shall be followed. 

The following clauses describe the additional requirements for the bearer independent CS core network. 



8.3.3.1 



MSC-A 



8.3.3. 1 . 1 Handover Request 

When the MSC-A server receives a MAP Prepare Subsequent Handover request containing a Handover Request 
message, it requests the MGW-A to provide a binding reference and a bearer address using the Prepare Bearer 
procedure. For speech calls, the MSC-A server shall provide the MGW-A with the speech coding information for the 
bearer. For non-speech calls the MSC-A server shall provide MGW-A with the same PLMN Bearer Capabihty [4] as 
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was provided at the last channel assignment. The MSC-A server uses the Change Flow Direction Procedure to request 
the MGW-A to set the Handover Device to initial state. The MSC-A server sends the Relocation Request message to 
the RNC-B containing the bearer address and binding reference (bullet 1 in figure 8.18/1). 

For Handover towards GERAN lu-mode, the MSC-A Server shall select a service according to the Channel Type 
received with the Handover Request message and the capabilities of the GERAN target cell, if the GERAN classmark 
was received. For speech calls, the MSC-A server shall additionally take into account the selected codec and the 
currently used codec received with MAP Prepare Subsequent Handover request, and the list of supported codecs. 

The MSC-A server shall indicate to the GERAN the selected service within the RANAP RELOCATION REQUEST 
message and shall set the RAB parameters within the RANAP RELOCATION REQUEST message according to the 
selected service. The MSC server shall not set codec information in the NAS Synchronisation Indicator (see [4]). 
Instead it shall set codec information in the GERAN BSC container. 

8.3.3.1 .2 Handover Command/Relocation Detect 

When the MSC-A server sends the MAP Prepare Subsequent Handover response message or alternatively if it receives 
a Relocation Detect message, the MSC-A server uses the Change Flow Direction procedure to requests the MGW-A to 
set the Handover Device to intermediate state (bullet 2 in figure 8.18/2). 

8.3.3.1 .3 Relocation Complete 

When the MSC-A server receives a Relocation Complete message, it informs the MSC-B server about reception of this 
message. MSC-A server then initiates call clearing towards the MSC-B server as described in clause 7.3. 

8.3.3.1.4 Interworking function 

The interworking function used by MGW-A before handover will also be used after handover. 

8.3.3.1.5 Codec handling 

The MGW may include a speech transcoder based upon the speech coding information provided to each bearer 
termination. 

8.3.3.1 .6 Voice Processing function 

Voice processing function(s) provided by MGW-A and MGW-B before handover, may be continued or modified by 
MGW-A after handover. 

8.3.3.1 .7 Failure Handling in MSC server 

When a procedure between the MSC-A server and the MGW fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have been already 
seized at the target access side then the resources shall be released using the Release Termination procedure. If the call 
is to be cleared, then it shall be handled as described in clause 7.3. 

8.3.3.2 MSC-B / MGW-B 

8.3.3.2.1 Handover Required 

For Handover towards GERAN lu mode the GERAN capabilities of the target cell will be indicated to the MSC-B 
server within the Handover Required message if the target cell provides different capabiUties than the current cell. If no 

information about the GERAN capabilities of the target cell are received within this message, the MSC-B server shall 
assume that the GERAN target cell will provide the same capabilities as the current cell (for details see [29]). 

The MSC-B server shall indicate to the MSC-A server the GERAN capabiUties of the target cell, if available, with the 
MAP Prepare Subsequent Handover request. For speech calls, the MSC-B server shall additionally indicate to the 
MSC-A server the selected codec and the currently used codec. 
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8.3.3.2.2 Handover Complete 

When the MSC-B server receives the Handover Complete message, it releases the A-interface line towards the BSC-A 
and requests the MGW-B to remove the bearer termination towards the BSC-A using the Release Termination 
procedure (bullet 3 in figure 8.18/2). 

8.3.3.2.3 Release of bearer towards MGW-A 

When the MSC-B server receives a call clearing indication from the MSC-A server, the MSC-B server handles it as 
described in subclause 7.2. 



8.3.3.2.4 Example 

Figure 8.17 shows the network model for Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSC. 
The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling 
(not applicable in case of GSM access) and the bearer. In the MGW the bearer termination Tl is used for the bearer 
towards RNC-B, the bearer termination T3 is used for the bearer towards MSC-A server, and the bearer termination T2 
is used for the bearer towards the succeeding/preceding MGW. In MGW-B the bearer termination T4 is used for the 
bearer towards BSC-A, bearer termination T5 is used for the bearer towards MGW-A. 




During Handover 
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After Handover 

Figure 8.17: Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSG 

(network model) 



Figure 8. 18 shows the message sequence example for the Subsequent Inter-MSC GSM to UMTS Handover back to the 
Anchor MSC. It is assumed that the Handover Device is located in the MGW (MGW-A) selected for the call 
establishment by the MSC server (MSC-A server) which controls the call and the mobihty management. 

In the example the MSC-A server requests MGW-A to seize RNC-B side bearer termination with specific flow 
directions. When the relocation is detected in RNC-B the MSC-A server requests to change the flow directions between 
the terminations within the context in MGW-A. When MSC-A server receives Handover Complete indication from 
RNC-B it transfers this indication to MSC-B server. MSC-B server releases the A-interface line towards the BSC-A. 
MSC-A server initiates call clearing towards MSC-B server. 
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Figure 8.18/1 : Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSC 

(message sequence chart) 
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Figure 8.18/2: Subsequent Inter-MSC GSM to UMTS Handover back to the Anchor MSC 

(message sequence chart) 

8.3.4 Subsequent Inter-MSC GSM to UMTS Hancdover to a third MSC 

The GSM to UMTS handover to a third MSC server (from MSC-B server to MSC-B server) is the combination of the 
two previous inter-MSC handover cases: 

for MSC-B server a subsequent GSM to UMTS handover from MSC-B server back to MSC-A server as 
described in clause 8.3.3; and 

for MSC-B server a basic GSM to UMTS handover from MSC-A server to MSC-B server as described in 
clause 8.3.2. 
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MSC-A server implements the corresponding parts of each handover case; i.e. access handling in MSC-A server is not 
included. 



If luCS on IP is supported by the MSG server, the Core Network side procedures described in clauses 8.3.1, 8.3.2, 8.3.3, 
8.3.4 shall apply. For the access bearer termination, the exchange of IP addresses via call control procedures is 
described in this clause. 

Before the MSC server starts the access bearer assignment, the MSC server requests the MGW to prepare for the access 
bearer using the Prepare_lP_Transport procedure. The MSC server requests the MGW to provide an IP Transport 
address and UDP Port and provides the MGW with the bearer characteristics. For speech calls, the MSC server shall 
provide the MGW with the speech coding information and conditionally GTT related information in accordance with 
3GPP TS 23.226 [28] for the bearer. For a non-speech call the MSC server also provides the MGW with a PLMN 
Bearer Capability [4]. After the MGW has replied with the IP address and UDP Port the MSC server requests access 
bearer assignment using the provided IP address and UDP Port in accordance with 3GPP TS 25.413 [26]. The IP 
addresses and UDP Ports of the MGW and the RNC are exchanged via the RANAP procedures. If the bearer transport 
is IP and luUP mode is Transparent, when the MSC receives the RANAP lu Relocation Request response, it shall send 
the RNC IP address and UDP Port to the MGW Access bearer termination using the Modify_IP_Transport_Address 
procedure. 

If the bearer transport is IP and luUP mode is Support, the MGW shall use the source IP address and UDP Port of the 
luUP Init packet received from the radio access network as the destination address for subsequent downhnk packets. 

The sequence is shown in figure 8.3.5/1. 



8.3.5 
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Figure 8.3.5/1 GSM to UMTS Handover with lu on IP 



8.4 GSM to GSM 



8.4.1 Intra-MSC Inter-BSS GSM to GSM Handover 

The procedures specified in 3GPP TS 23.009 [8] for "Intra-MSC Handover" shall be followed. The following clauses 
describe the additional requirements for the bearer independent CS core network. 



8.4.1.1 Handover Required 

When the MSC server receives a Handover Required message, it requests the MGW to seize a TDM circuit, using the 
Reserve Circuit procedure. For non-speech calls the MSC server shall provide the MGW with the GSM Channel coding 
properties and the same PLMN Bearer Capability [4] as was provided at the last access bearer assignment. The MSC 
server uses the Change Flow Direction procedure to request the MGW to set the Handover Device to initial state. The 
MSC server sends the Handover Request message to the BSC-B containing the CIC (bullet 1 in figure 8.20/1). 
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8.4.1 .2 Handover Request Acknowledge 

For non-speech calls after receiving Handover Request Acknowledge message if the assigned GSM Channel coding 
properties differ from the previously provided ones the MSG server provides the MGW-A with the assigned GSM 
Channel coding properties using the Modify Bearer Characteristics procedure (bullet 2 in figure 8.20/1). 

8.4.1 .3 Handover Command/Handover Detect 

When the MSG server sends the Handover Command message or alternatively if it receives the Handover Detect 
message, the MSG server uses the Change Flow Direction procedure to requests the MGW to set the Handover Device 
to intermediate state (bullet 3 in figure 8.20/1). 

8.4.1 .4 Handover Complete 

When the MSG server receives the Handover Complete message, it releases the A-interface line towards BSC-A. The 
MSC server also requests the MGW to set the Handover Device to its final state by removing the bearer termination 
towards the BSC-A, using the Release Termination procedure (bullet 4 in figure 8.20/2). 

8.4.1 .5 Inten/vorking function 

The interworking function used by the MGW before handover will also be used after handover. 

8.4.1 .6 Voice Processing function 

After handover, the MGW may continue or modify voice processing function(s) provided to each bearer termination. 

8.4.1 .7 Failure Handling In MSC server 

When a procedure between the MSC server and the MGW fails the MSC server shall handle the failure as an internal 
error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have already been seized at 
the target access side then the resources shall be released using the Release Termination procedure. If the call is to be 
cleared, then it shall be handled as described in clause 7.3. 
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8.4.1.8 Example 

Figure 8.19 shows the network model for the Intra-MSC GSM to GSM Handover. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer. The bearer termination Tl is used for the bearer towards 
BSC-A, bearer termination T3 is used for the bearer towards BSC-B and the bearer termination T2 is used for the bearer 
towards the succeeding/preceding MGW. 




V J 

Before Handover 




During Handover 




^ J 



After Handover 

Figure 8.19: Intra-IVISC GSIV! to GSIV! Handover (networic model) 

Figure 8.20 shows the message sequence example for the Intra-MSC GSM to GSM Handover. It is assumed that the 
Handover Device is located in the MGW selected for the call establishment by the MSG server, which controls the call 
and the mobility management. 
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In the example the MSC server requests seizure of BSC-B side bearer termination with specific flow directions. The 
MSC server starts handover execution by sending Handover Request towards BSC-B. When the handover is detected in 
BSC-B the MSC server requests to change the flow directions between the terminations within the context. When MSC 
server receives Handover Complete indication from BSC-B it releases the A-interface line towards the BSC-A. Finally 
the MSC server requests the MGW to release BSC-A side bearer termination. 
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Figure 8.20/1 : Intra-MSC GSM to GSM Handover (message sequence chart) 
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8.4.1.9 



Figure 8.20/2: intra-IUlSC GSIUI to GSIUI Handover (message sequence chart) 
Intra-MSC GSM to GSM Handover for A interface over IP 



When the MSC server receives the BSSAP Handover Required message, it requests the MGW to reserve an RTP bearer 
termination using the Reserve RTP Connection Point procedure. The MSC server requests the MGW to reserve an IP 
address and UDP port. The MSC server uses the Change Flow Direction procedure to request the MGW to set the 
Handover Device to initial state. 



The MGW reserves the RTP termination and indicates the IP address and UDP port number to the MSC server. The IP 
addresses and UDP ports of the MGW is sent to the BSC in the BSSMAP Handover Request message. When the MSC 
server receives the BSSMAP Handover Request- Ack message, it shall send the BSC IP address and UDP Port number 
to the MGW using the Configure RTP Connection Point procedure. 

The sequence is shown in Figure 8.4.1.9/1. 
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Figure 8.4.1.9/1 : Intra-MSC GSM to GSM Handover for AolP (message sequence chart) 

8.4.2 Basic Inter-MSC GSM to GSM Handover 

The procedures specified in 3GPP TS 23.009 [8] for "Basic Handover Procedure Requiring a Circuit Connection 
between MSC-A and MSC-B" shaU be foUowed. The following clauses describe the additional requirements for the 
bearer independent CS core network. 

8.4.2.1 MSC-A /MGW-A 

8.4.2.1 .1 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer establishment between MGW-A and MGW-B is as described for a Basic Mobile Originating 
Call, using either forward or backward bearer establishment. For non-speech calls the MSC-A server shall provide 
MGW-A with the GSM Channel coding properties and the same PLMN Bearer Capability [4] as was provided at the 
last access bearer assignment. The MSC-A server also uses the Change Flow Direction procedure to request MGW-A to 
set the Handover Device to initial state (bullet 3 in figure 8.22/2). 



8.4.2.1.2 



Handover Command/Handover Detect 



When the MSC-A server sends the Handover Command message or alternatively if it receives the Handover Detect 
message, the MSC-A server uses the Change Flow Direction procedure to requests MGW-A to set the Handover Device 
to intermediate state (bullet 4 in figure 8.22/2). 
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8.4.2.1.3 Handover Complete 

When the MSC-A server receives the Handover Complete message, it releases the A-interface line towards the BSC-A. 
The MSC-A server also requests MGW-A to set the Handover Device to its final state by removing the bearer 
termination towards the BSC-A, using the Release Termination procedure (bullet 5 in figure 8.22/2). 

8.4.2.1.4 Interworking function 

The interworking function used by MGW-A before handover wdU also be used after handover. 

8.4.2.1 .5 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be modified or disabled by MGW-A after 
handover. 

8.4.2.1 .6 Failure Handling in MSG server 

When a procedure between the MSC-A server and MGW-A fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If call establishment towards the 
MSC-B server has already started then the call towards MSC-B server shall be cleared as described in clause 7.3. If the 
original call is to be cleared, then it shall be handled as described in clause 7.3. 

8.4.2.2 MSC-B / MGW-B 

8.4.2.2.1 MGW selection 

The MSC-B server selects an MGW when it receives Prepare Handover Request message (bullet 1 in figure 8.22/1). 

8.4.2.2.2 Bearer establishment towards BSC-B 

When the MSC-B server has selected MGW-B it requests MGW-B to seize a TDM circuit, using the Reserve Circuit 
procedure. The MSC-B server sends the Handover Request message to the BSC-B containing the CIC (bullet 2 in 
figure 8.22/1). 

8.4.2.2.3 Bearer establishment between MGW-A and MGW-B 

The handling of the bearer estabhshment between MGW-A and MGW-B is as described for a Basic Mobile 
Terminating Call, using either forward or backward bearer establishment. 

8.4.2.2.4 Voice Processing function 

Voice processing function(s) provided by MGW-A before handover, may be continued or modified by MGW-B after 
handover. 

8.4.2.2.5 Failure Handling in MSG server 

When a procedure between the MSC-B server and MGW-B fails the MSC-B server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-B resources have already 
been seized at the target access side then the resources shall be released using the Release Termination procedure. The 
call from MSC-A server shall be released as described at clause 7.1. 

8.4.2.2.6 Example 

Figure 8.21 shows the network model for the Basic Inter-MSC GSM to GSM. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer. In MGW-A the bearer termination Tl is used for the bearer 
towards BSC-A, bearer termination T3 is used for the bearer towards MGW-B, and the bearer termination T2 is used 
for the bearer towards the succeeding/preceding MGW. In MGW-B the bearer termination T4 is used for the bearer 
towards BSC-B, bearer termination T5 is used for the bearer towards MGW-A. 
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After Handover 

Figure 8.21 : Basic Inter-IVISC GSIVI to GSIV! Handover (networl< model) 



Figure 8.22 shows the message sequence example for the Basic Inter-MSC GSM to GSM Handover. 

It is assumed that the Handover Device is located in the MGW (MGW- A) selected for the call establishment by the 
MSG server (MSC-A server) which controls the call and the mobility management. 

In the example the MSC-B server requests MGW-B to seize BSC-B side bearer termination. The call is established 
between MSC-A server and MSC-B server, and the bearer is established between MGW- A and MGW-B. When the 
handover is detected in BSC-B the MSC-A server requests to change the flow directions between the terminations 
within the context in MGW- A. When MSC-A server receives Relocation Complete indication from MSC-B server it 
releases the A-interface line towards the BSC-A. Finally MSC-A server requests MGW-A to remove BSC-A side bearer 
termination. 
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Figure 8.22/1 : Basic Inter-IVISC GSIVI to GSIVI l-landover (message sequence chart) 
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Figure 8.22/2: Basic Inter-IVISC GSIV! to GSIV! IHandover (message sequence chart) 



8.4.2.3 



Basic Inter-MSC GSM to GSM Handover for A Interface over IP 



If AoIP is supported by the MSC server, the Core Network side procedures described earlier in 8.4.2 shall apply. For 
the access side termination, the exchange of IP addresses via call control procedures is described in this clause. 

When the MSC-B server receives the MAP Prepare Handover Request., it requests the MGW-B to reserve an RTP 
bearer termination using the Reserve RTP Connection Point procedure. The MSC-B server requests the MGW-B to 
reserve an IP address and UDP port. 

The MGW-B reserves the RTP termination and indicates the IP address and UDP port number to the MSC-B server. 
The IP addresses and UDP ports of the MGW is sent to the BSC-B in the BSSMAP Handover Request message. When 
the MSC-B server receives the BSSMAP Handover Request- Ack message, it shall send the BSC-B IP address and UDP 
Port number to the MGW-B using the Configure RTP Connection Point procedure. 
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Figure 8.4.2.3/1 : Basic Inter-IUlSC GSIUl to GSIUl IHandover for AolP (message sequence cliart) 



8.4.3 Subsequent Inter-MSC GSM to GSM Handover back to the Anchor 
MSG 

The procedures specified in 3GPP TS 23.009 [8] for "Subsequent Handover from MSC-B to MSC-A requiring a Circuit 
Connection between 3G_MSC-A and 3G_MSC-B" shall be followed. The following clauses describe the additional 
requirements for the bearer independent CS core network. 



8.4.3.1 MSC-A /MGW-A 

When the MSC-A server receives a MAP Prepare Subsequent Handover request containing a Handover Request 
message, it requests MGW-A to seize a TDM circuit, using the Reserve Circuit procedure. For non-speech calls the 
MSC-A server shall provide MGW-A with the GSM Channel coding properties and the same PLMN Bearer Capabihty 
[4] as was provided at the first access bearer assignment The MSC-A server uses the Change Flow Direction Procedure 
to request MGW-A to set the Handover Device to initial state. The MSC-A server sends the Handover Request message 
to the BSC-B containing the CIC (bullet 1 in figure 8.24/1). 



8.4.3. 1 . 1 Handover Request Acknowledge 

For non-speech calls after receiving Handover Request Acknowledge message if the assigned GSM Channel coding 
properties differ from the previously provided ones the MSC-A server provides the MGW-A with the assigned GSM 
Channel coding properties using the Modify Bearer Characteristics procedure (bullet 2 in figure 8.24/2). 
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8.4.3.1 .2 Handover Command/Handover Detect 

When the MSC-A server sends the MAP Prepare Subsequent Handover response message or alternatively if it receives 
the Handover Detect message, the MSC-A server uses the Change Flow Direction procedure to request MGW-A to set 
the Handover Device to intermediate state (bullet 3 in figure 8.24/2). 



8.4.3.1.3 Handover Complete 

When the MSC-A server receives the Handover Complete message, it informs the MSC-B server about reception of this 
message. The MSC-A server then initiates call clearing towards the MSC-B server as described in clause 7.3. 



8.4.3.1 .4 Interworking function 

The interworking function used by MGW-A before handover will also be used after handover. 



8.4.3.1 .5 Voice Processing function 

Voice processing function(s) provided by MGW-A and MGW-B before handover, may be continued or modified by 
MGW-A after handover. 



8.4.3.1 .6 Failure Handling in MSG server 

When a procedure between the MSC-A server and MGW-A fails the MSC-A server shall handle the failure as an 
internal error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW-A resources have akeady 
been seized at the target access side then the resources shall be released using the Release Termination procedure. If the 
call is to be cleared, then it shall be handled as described in clause 7.3. 



8.4.3.2 MSC-B/MGW-B 



8.4.3.2.1 Handover Complete 

When the MSC-B server receives the Handover Complete message, it releases the A-interface line towards the BSC-A 
and requests the MGW-B to remove the bearer termination towards the BSC-A using the Release Termination 
procedure (bullet 4 in figure 8.24/2). 



8.4.3.2.2 Release of bearer towards MGW-A 

When the MSC-B server receives a call clearing indication from the MSC-A server, the MSC-B server handles it as 
described in clause 7.2. 



8.4.3.2.3 



Example 



Figure 8.24 shows the network model for the Subsequent Inter-MSC GSM to GSM Handover back to the Anchor MSC. 
The "squared" line represents the call control signalling. The "dotted" line represents the bearer. In MGW-A the bearer 
termination T6 is used for the bearer towards BSC-B, bearer termination T3 is used for the bearer towards MGW-B, and 
the bearer termination T2 is used for the bearer towards the succeeding/preceding MGW. In MGW-B the bearer 
termination T4 is used for the bearer towards BSC-A, bearer termination T5 is used for the bearer towards MGW-A. 
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Figure 8.23: Subsequent Inter-IVISC GSIVI to GSIVI Handover bacl< to the Anchor lUISC 

(networl< model) 

Figure 8.24 shows the message sequence example for the Subsequent Inter-MSC GSM to GSM Handover back to the 
Anchor MSG. It is assumed that the Handover Device is located in the MGW (MGW-A) selected for the call 
establishment by the MSG server (MSG-A server) which controls the call and the mobility management. 

In the example the MSG-A server requests MGW-A to seize BSG-B side bearer termination with specific flow 
directions. When the handover is detected in BSG-B the MSG-A server requests to change the flow directions between 
the terminations within the context in MGW-A. When MSG-A server receives Relocation Gomplete indication from 
BSG-B it transfers this indication to MSG-B server. MSG-B server releases the A-interface line towards the BSG-A. 
MSG-A server initiates call clearing towards MSG-B server. 
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Figure 8.24/1 : Subsequent Inter-MSC GSM to GSM Handover back to the Anchor MSG 

(message sequence chart) 
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Figure 8.24/2: Subsequent Inter-MSC GSM to GSM Handover back to the Anchor MSC 

(message sequence chart) 
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8.4.3.3 Subsequent Inter-MSC GSM to GSM Handover back to the anchor MSG for 
A Interface over IP 

When the MSC-A server receives the MAP Prepare Subsequent Handover Request message, it requests the MGW-A to 
reserve an RTP bearer termination using the Reserve RTP Connection Point procedure. The MSC-A server requests the 
MGW-A to reserve an IP address and UDP port. The MSC-A server uses the Change Flow Direction procedure to 
request the MGW-A to set the Handover Device to initial state. 

The MGW-A reserves the RTP termination and indicates the IP address and UDP port number to the MSC-A server. 
The IP addresses and UDP ports of the MGW-A is sent to the BSC-B in the BSSMAP Handover Request message. 
When the MSC-A server receives the BSSMAP Handover Request- Ack message, it shall send the BSC-A IP address 
and UDP Port number to the MGW-B using the Configure RTP Connection Point procedure. 

The sequence is shown in Figure 8.4.3.3/1. 
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Figure 8.4.3.3/1 : Subsequent Inter-MSC GSM to GSM Handover back to the anchor MSG for AolP 

(message sequence chart) 



8.4.4 Subsequent GSM to GSM Handover to a third MSG 

The GSM to GSM handover to a third MSC server (from MSC-B server to MSC-B server) is the combination of the 
two previous inter-MSC handover cases: 

- for MSC-B server a subsequent GSM to GSM handover from MSC-B server back to MSC-A server as described 
in clause 8.4.3; and 

- for MSC-B server a basic GSM to GSM handover from MSC-A server to MSC-B server as described in 
clause 8.4.2. 

MSC-A server implements the corresponding parts of each handover case, i.e. access handling in MSC-A server is not 
included. 
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8.4.5 BSS Internal Handover 

8.4.5.1 Introduction 

The procedures specified in 3GPP TS 23.009 [8] for "BSS Internal Handover" shall be followed. The protocol messages 
are defined in 3GPP TS 48.008 [27]. The following clauses describe the additional requirements for the bearer 
independent CS core network due to BSS internal handover for A-Interface User Plane over IP (AoIP). 

A BSS Internal Handover may be initiated by the BSS on its own, or triggered by the MSG server with the transmission 
of an Internal Handover Enquiry message to the BSS. 

8.4.5.2 Internal Handover Required 

When the MSG server receives an Internal Handover Required message, it requests the MGW to seize a TDM circuit 
using the Reserve Gircuit procedure or an RTP termination using the Reserve and Gonfigure RTP Gonnection Point 
procedure. In the latter case, the MSG server sends the BSG IP address and UDP port and the determined A-Interface 
Godec Type/Gonfiguration to the MGW and requests the MGW to reserve a local IP address and UDP port. 

NOTE: During a BSS Internal handover procedure involving an IP-based target A-Interface Type before and after 
the handover, the BSG IP addresses and UDP ports used before and after the handover may be identical or 
different. This is transparent to the MSG Server. In the former case, the BSG can receive on its BSG IP 
address and UDP port identical RTP flows received from the source and target access terminations 
reserved in the MGW. 

For non-speech calls the MSG server shall provide the MGW with the GSM Ghannel coding properties and the same 
PLMN Bearer Gapability as was provided at the last access bearer assignment. The MSG server uses the Ghange Flow 
Direction procedure to request the MGW to set the Handover Device to initial state. 

The MGW reserves the TDM circuit or RTP termination and indicates in the latter case its own IP address and UDP 
port to the MSG server. The MSG server then sends the Intemal Handover Gommand message to the BSG containing 
the speech codec type/configuration chosen and either the GIG or the MGW IP address and UDP port. 

If the resources requested by the BSS in the Intemal Handover Required message (e.g. codec type or codec 
configuration, interface type, etc.) are not available, an Internal Handover Required Reject message shall be returned to 
the BSS with the appropriate failure cause, and the procedure shall be terminated. 

8.4.5.3 Internal Handover Command/Handover Detect 

When the MSG server sends the Intemal Handover Gommand message or altematively if it receives the Handover 
Detect message, the MSG server uses the Ghange Flow Direction procedure to requests the MGW to set the Handover 
Device to intermediate state (bullet 2 in figure 8.4.5.8.2). 

8.4.5.4 Handover Complete 

When the MSG server receives the Handover Gomplete message, it requests the MGW to set the Handover Device to its 
final state by removing the bearer termination towards the source BSG IP address and UDP port number, using the 
Release Termination procedure (bullet 3 in figure 8.4.5.8.2). 

8.4.5.5 Inten/vorking function 

The interworking function used by the MGW before handover will also be used after handover. 

8.4.5.6 Voice Processing function 

After handover, the MGW may continue or modify voice processing function(s) provided to each bearer termination. 

8.4.5.7 Failure Handling in MSG server 

When a procedure between the MSG server and the MGW fails the MSG server shall handle the failure as an internal 
error in accordance with 3GPP TS 23.009 [8] and 3GPP TS 29.010 [23]. If MGW resources have already been seized 
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for BSS internal handover then the resources shall be released using the Release Termination procedure. If the call is to 
be cleared, then it shall be handled as described in clause 7.3. 

If the MSC server receives the Handover Failure message during BSS internal handover procedure, it shall release 
MGW resources if they have been seized for BSS internal handover using the Release Termination procedure. 



8.4.5.8 Example for a successful BSS Internal Handover 

Figure 8.4.5.8.1 shows the network model for the BSS Internal Handover, where IP transport is used on the A interface 
before and after the BSS Internal Handover procedure. The "squared" line represents the call control signalling. The 
"dotted" line represents the bearer. The bearer termination Tl is used for the bearer towards the source BSC IP address 
and UDP port number Ta, bearer termination T3 is used for the bearer towards the target BSC IP address and UDP port 
number Tb and the bearer termination T2 is used for the bearer towards the succeeding/preceding MGW. 




BSC 



Before BSS Internal Handover 




During BSS Internal Handover 
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After BSS Internal Handover 
Figure 8.4.5.8.1 : Intra-MSC BSS Internal Handover (network model) 

Figure 8.4.5.8.2 shows the message sequence example for the Intra-MSC BSS Internal Handover. 

In the example, the MSC server receives the Internal Handover Required message and requests the MGW to reserve an 
RTP bearer termination (T3) using the Reserve and Configure RTP Connection Point procedure with specific flow 
directions. 

The MSC server starts the Internal Handover execution by sending the Internal Handover Command towards the BSC 
in which it provides the IP address and UDP port of the target MGW RTP termination (T3). When the handover is 
detected in the BSC, the MSC server requests the MGW to change the flow directions between the terminations within 
the context. When the MSC server receives the Handover Complete indication from the BSC it requests the MGW to 
release the bearer termination Tl towards the source BSC IP address and UDP port number Ta that was used before the 
BSS Internal Handover was initiated. The sequence is shown in Figure 8.4.5.8.2. 
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Figure 8.4.5.8.2: Intra-MSC BSS Internal Handover for AolP (message sequence chart) 

8.5 Handling of GSM Services after UIVITS to GSIVI Handover 

The handling of GSM services after handover in the Bearer Independent CS Core Network architecture is as for the 
corresponding UMTS services, if not stated differently. 



9 Compatibility Issues 

A Release 4 (or later) node, according to 3GPP TS 23.205, is backward compatible with a Release 99 (or earlier) node. 

9.1 Interworking with GERAN (A i/f) 
9.1.1 IntrocJuctlon 

The A-interface signalling terminates in the MSG server and the user plane terminates in the MGW. TDM and/or IP 
transports may be supported on the A-interface. The MSG server uses the Mc interface to remotely control the TDM or 
IP resources in the MGW. 

For intra-MSG handover, the target A-interface is handled as described in clause 8. If the target A-interface user plane 
terminates in a different MGW from the MGW that terminates the serving A-interface user plane, a bearer has to be 
established between the two MGWs using Prepare Bearer and Establish Bearer procedures. Because the same MSG 
server controls both MGWs, no external call control signalling is involved. 
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It is important to note that the separation between the user and control planes remains the same before and after 
interaction with services in the 3G BICC CSCN. 

9.1.2 A interface over TDM 

Only one MSG server may control the TDM circuits connected to one GERAN node. 

For each TDM circuit a physical termination is provisioned in the MGW. The TDM circuit is identified by the 
termination Id in the Mc interface. Since TDM circuits are also grouped together, the physical termination Ids are 
structured in accordance with the grouping of TDM circuits. The MSG server also knows the termination Ids and the 
grouping of termination Ids. The physical termination exists as long as the TDM circuit(s) exists in the MGW. 

Figure 9.1 shows the network model for the A-interface. The "squared" line represents the call control signalling and the 
"dotted" line represents the TDM circuits. The terminations Tl-Tn represent the TDM circuits in the MGW. The MSG 
server has a mapping table between circuits GIGl-GIGn and the terminations Tl-Tn. 




Figure 9.1 TDM circuits used for A-interface (networic model) 

For call-independent transactions the general (G)MSG server-MGW procedures, as described in clause 10, apply to the 
physical terminations in the same way as to any other terminations. 

For call related transactions the handling as described in the clauses 6, 7 and 8 apply to physical terminations in the 
same way as any other terminations. All call related procedures, except Prepare Bearer, Establish Bearer, Release 
Bearer and Tunnel Information Up/Down, as described in clause 16, apply to the physical terminations in the same way 
as any other terminations. 



10 General (G)MSC server-MGW Procedures 
10.1 MGW Unavailable 

The (G)MSG server recognises that the MGW is unavailable in the following 4 cases: 
1 . The signalling connection is unavailable 
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(G)MSC-S MGW 












Signalling Connection Failure 



Figure 10.1: Signalling connection failure 



2. The MGW indicates the failure condition to all connected (G)MSC servers 



(G)MSC-S 




MGW 






MGW Out of Service 






MGW Out of Service Ack 


► 



Figure 10.2: iVIGW indicates the Failure/IVIaintenance locking 

The failure indication indicates that the MGW will soon go out of service and that no new connections should be 
established using this MGW. The MGW can choose between the "graceful" and the "forced" method, hi the graceful 
method the connections are cleared when the corresponding calls are disconnected. In the forced method all connection 
are cleared immediately. 

3. The (G)MSC server recognises that the MGW is not functioning correctly, e.g. because there is no reply on 
periodic sending of Audits. The periodic sending of Audits by (G)MSC server should go on. 

4. The MGW indicates the maintenance locking condition to all concerned (G)MSC servers. 

The maintenance locking indication indicates that the MGW is locked for new calls and that no new connections shall 
be established using this MGW. The MGW can choose between the "graceful" and the "forced" method. In the graceful 
method the connections are cleared when the corresponding calls are disconnected. In the forced method all connection 
are cleared immediately 

In all of the above cases the (G)MSC server shall prevent the usage of the MGW until the MGW has recovered or the 
communication with the MGW is restored. The (G)MSC server shall prohibit the surrounding network from seizing 
circuits connected to the unavailable TDM access by sending blocking messages. 

10.2 MGW Available 

The (G)MSC server discovers that the MGW is available when it receives an MGW Communication Up message or an 
MGW Restoration message. If the (G)MSC does not wish to sustain an association with the MGW, the response sent to 
the MGW may indicate an alternative MGCId signalling address, in which case the MGW shall not consider itself 
registered and should preferably attempt to re-register wdth this alternative MGC before any further alternate MGCs. 
Otherwise, the response shall not indicate any alternative MGCId signalhng address. 

When the (G)MSC server discovers that the MGW is available the following shall occur: 

1. Signalhng recovery 
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The MGW indicates to all connected (G)MSC servers that the signalling connection is restored. Any changes to the 
physical termination state during the loss of communication shall be reported by the MGW using Termination Out Of 
Service (10.7) or Termination Restoration (10.8), otherwise the (G)MSC Server can assume that Terminations service 
state has not changed. To avoid unsuccessful calls for physical terminations which went out of service during the loss of 
communication but have not yet been reported by the MGW the MSG Server may Audit the physical terminations 
before it uses them. 

NOTE: Auditing in this case will cause duplicate signalUng. 



(G)MSC-S MGW 






SignalUng in service 








MGW Commumcation Up 



MGW Communication Up Ack 





Figure 10.3: Communication goes up 



2. MGW restoration/maintenance unlocking indication. 

The MGW indicates to all connected (G)MSC servers that normal operation has resumed. Changes of the physical 
termination state during the connection break shall be reported by the MGW using Termination Out Of Service (10.7) 
and Termination restoration (10.8) procedures, otherwise the (G)MSC Server can assume that Terminations service 
state has not changed. To avoid unsuccessful calls for physical terminations which went out of service during the loss of 
communication but have not yet been reported by the MGW the (G)MSC Server may Audit the physical terminations 
before it uses them. 

NOTE: Auditing in this case will cause duplicate signalUng. 



(G)MSC- MG 






Signalling in 
► 






^ MGW Restoration 


MGW Restoration Ack 





Figure 10.4: MGW indicates recovery from a failure/or maintenance uniocl(ing 

NOTE: This procedure may be used after recovery from a signaUing failure. 

3. The (G)MSC server recognises that the MGW is now functioning correctly, e.g. because there is a reply on 
periodic sending of Audits. 

After this the (G)MSC server can use the MGW. If the corresponding devices of the surrounding network are blocked, 
unblocked messages shall be sent to the nodes concemed for devices that are in service: the (G)MSC Server has 
determined the actual state of the physical devices either by receiving Termination Restoration procedure (10.8) or by 
performing an Audit.. 

If none of 1,2, and 3 happens the (G)MSC server can initiate the (G)MSC Server Ordered Re-register procedure. 
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10.3 MGW Recovery 

If the MGW recovers from a failure, is maintenance unlocked, or it has been restarted, it registers to its known (G)MSC 
servers using the MGW Restoration procedure or the MGW Registration procedure. The MGW can indicate whether 
the Service has been restored or whether it has restarted with a cold or warm boot. If the (G)MSC does not wish to 
sustain an association with the MGW, the response sent to the MGW may indicate an alternative MGCId signalUng 
addres, in which case the MGW shall not consider itself registered and should preferably attempt to re -register with this 
alternative MGC before any further alternate MGCs. Otherwise, the response shall not indicate any alternative MGCId 
signalling address. 



(G)MSC-S MGW 






MGW Restoration 






(Service Restored) 

MGW Restoration Ack 


(G)MSC-S address) 



Figure 10.5/1: MGW Restoration 



(G)MSC-S MGW 






MGW Register 






(ColdAVarmboot) 
MGW Register Ack 


(G)MSC-S address) 



Figure 10.5/2 lUlGW Registration 



After the recovery the (G)MSC server can use the MGW. After a MGW warm boot or service restored, the (G)MSC 
Server can assume the physical terminations state has not changed. Changes of the physical termination state during the 
connection break shall be reported by the MGW using Termination Out Of Service (10.7) and Termination restoration 
(10.8) procedures. To avoid unsuccessful calls for physical terminations which went out of service during the loss of 
communication but have not yet been reported by the MGW the MSG Server may Audit the physical terminations 
before it uses them. 

NOTE: Auditing in this case will cause duplicate signalUng. 



After receiving a MGW Register (with cold boot) the (G)MSC Server shall audit the termination state of all physical 
terminations (10.9) if it has not been specifically informed of the actual service state since receiving the MGW service 
change on ROOT (Register) via independent service change commands (10.7 or 10.8). The (G)MSC Server shall 
thereby determine the actual Service State of devices. If the corresponding devices of the surrounding network are 
blocked, unblocked messages are sent to the nodes concerned for all devices that are in service. 
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10.4 (G) MSG server Recovery 

10.4.1 General 

If an MGW-unavailable condition is provoked by a failure/recovery action, the (G)MSC server recovery sequence will, 
from an information flow point of view, look like MGW unavailable and then MOW available. If an MGW-unavailable 
condition is not provoked, the (G)MSC server recovery sequence will look like MGW available. 

After the information flow, the terminations affected by the recovery action are released. 

1 0.4.2 (G)MSC Server Restoration 



(G)MSC-S MGW 




Tw 


(G)MSC recovery complete 
Signalling working 






Communication Up/MGW 
Restoration 


Communication Up/MGW 
Restoration Ack 


(G)MSC Server Restoration ^ 


warm, cold ( boot) note " 
(G)MSC Server Restoration Ack 





Figure 10.6: (G)i\/ISC Server Restoration 



NOTE: Normal release procedure may also be initiated. 

After the recovery action is complete and it is possible to signal to the MGW the (G)MSC server starts a timer Tw. If 
recovery indications are not received (MGW Communication Up or MGW Restoration) from the MGW during Tw an 
Audit is sent. If the (G)MSC server receives a recovery indication or MGW communication up indication, it shall 
acknowledge the indication before the (G)MSC Server Restoration may be sent or the release procedure is initiated. 

10.5 MGW Re-register 

When the (G)MSC requests an MGW to perform a registration (see clause 10.2, 10.3 and 10.6), the MGW performs a 
re-registration to the (G)MSC which is defined in the (G)MSC address. If the (G)MSC Server is uncertain of the 
termination service state of physical terminations after the Re-Register it shall use the Audit Procedure (10.9). Changes 
of the physical termination state during the connection break shall be reported by the MGW using Termination Out Of 
Service (10.7) and Termination restoration (10.8) procedures. 
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(G)MSC-S MGW 






mvjW Ke-regisier 






MGW Re-register Ack 





Figure 10.7: Re-registration of an lUIGW 



1 0.6 MGW Re-registration Ordered by (G)MSC server 

If the (G)MSC server knows that communication is possible, but the MGW has not registered, the (G)MSC server can 
order re-registration of the MGW. 



(G)MSC-S 




MGW 






G)MSC Server Ordered Re-reg 


ister 






((G)MSC address) 
:G)MSC Server Ordered Re-register 


Ack 



Figure 10.8: Re-registration ordered by the (G)MSC server 

If the re-registration request is accepted the MGW uses the MGW Re-register procedure to register with the (G)MSC 
server. 

10.7 Removal from Service of a Physical Termination 

The MGW indicates the removal from service of a physical termination using the Termination Out-of-Service 
procedure. In this procedure the MGW indicates which termination is to be removed from service and whether the 
"graceful" or "forced" method wdll be used. In the graceful method a possible connection is cleared when the 
corresponding call is discoimected. In the forced method the possible connection is cleared immediately. 
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Termination Out-Of-Service Ack 





Figure 10.9: Removai from service of a Phiysicai Termination 

The (G)MSC server shall prevent the use of the Terimnation(s) concerned until the physical termination is restored to 
service. 

10.8 Restoration to Service of a Physical Termination 

If the physical termination is restored to service, the MGW shall report it to the (G)MSC server(s) using the 
Termination Restoration procedure. 



(G)MSC-S 




MGW 






Termination Restoration 






(Termination(s)) 
Termination Restoration Ack 





Figure 10.10: Restoration to service of a Physical Termination 

The (G)MSC server can use the physical termination when the termination has been restored to service. If the 
corresponding devices of the surrounding network are blocked, the (G)MSC server sends an unblocked message to each 
node concerned. 

10.9 Audit of IVIGW 
10.9.1 Audit of Value 

The (G)MSC server may request the MGW to report the current values assigned to distinct objects in the MGW. 
Objects, which can be addressed, are listed in 3GPP TS 29.232 [6]. This procedure shall be used when a change has 
occurred in the (G)MSC server such that the server is unsure of the current Service State of Terminations, such as 
restart or new trunks configured in the server. For any situation where a change to the Service State occurs in the MGW 
the (G)MSC server shall expect the Service State to be reported by Termination Restoration (10.8) or Termination Out 
Of Service (10.7). 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



136 



ETSI TS 123 205 V9.2.0 (2011-04) 



(G)MSC-S MGW 






Audit Value 






(Object(s)) 
Audit Value Ack 


(values per requested object) 



Figure 10.11: Audit Vaiue 



10.9.2 Audit of Capability 

The (G)MSC server may request the MGW to report the capabilities of distinct objects in the MGW. Objects, which can 
be addressed, are listed in 3GPP TS 29.232 [6]. 



(G)MSC-S MGW 
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(Object(s)) 

Audit Capability Ack 
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Figure 10.12: Audit Capability 



10.10 MGW Capability Change 

The MGW reports a change of capabihty of distinct objects in the MGW. Objects, which can be addressed, are listed in 
3GPPTS 29.232 [6]. 



(G)MSC-S MGW 
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Figure 10.13: Capability Update 

The (G)MSC server can use the Audit Value and/or Audit Capability procedures to obtain further information, about the 
objects whose capabilities have changed. 
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10.11 Void 

10.12 (G)MSC Server Out of service 
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(G)MSC Server Out of Service ^ 






(Forced/graceful) 
(G)MSC Server Out of Service Ack 





Figure 10.14: (G)MSC Server Out of Service 



If a (G)MSC server discovers that it wants to go out of service it starts a (G)MSC Server Out of Service procedure. The 
(G)MSC server can indicate whether it requires the context to be cleared immediately (forced) or cleared as the bearer 
control protocol clears the bearer (Graceful). Physical terminations are always cleared when the (G)MSC Server Out of 
Service indication reaches the MGW. 

10.13 IVIGW Resource Congestion Handling - Activate 

When the (G)MSC server requires that a MGW congestion notification mechanism be applied in the MGW, the 
(G)MSC server shall use the MGW Resource Congestion Handling - Activate procedure towards the MGW. 



(G)MSC-S 




MGW 






MGW Resource Congestion 
Handling - Activate 






MGW Resource Congestion 
Handling - Activate -Ack 





Figure 10.15: lUIGW Resource Congestion Handling - Activate 

10.14 IVIGW Resource Congestion Handling -Indication 

When the (G)MSC server receives a load reduction notification from the MGW via the MGW Resource Congestion 
Handling - Indication procedure, the (G)MSC server tries to reduce the processing load that the (G)MSC server creates 
on the MGW. The MGW shall decide the actual level of traffic reduction. 
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Figure 10-17: lUIGW Resource Congestion IHandling - Indication 
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10.15 Control association monitoring 

Monitoring of the H.248 control association may be performed by monitoring the status of the transport Unk association 
where the transport protocol provides sufficient coupling to the H.248. 1 protocol, i.e. if the transport link association is 
disconnected when no local H.248. 1 protocol connection exists. 

An alternative method for the MGW to detect loss of the MGC may be achieved by requesting the MGW to poU the 

(G)MSC periodically 

Upon registration of a MGW, the (G)MSC server may use the Inactivity Timeout - Activate procedure towards the 
MGW to request the MGW to monitor incoming messages for periods of silence exceeding the maximum inactivity 
timer value. 
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Inactivity Timeout Activate 














Inactivity Timeout Activate Ack 

















Figure 10.15.1 : Inactivity Timeout - Activate 



Upon receipt of an inactivity timeout notification from the MGW via the Inactivity Timeout -Indication procedure, the 
(G)MSC server shall send a reply to the MGW. If the MGC has failed, the MGW will not receive a reply. 
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Inactivity Timeout - Indication Ack ^ 





Figure 10.15.2: Inactivity Timeout - Indication 



If no Inactivity Timeout - Indication Ack reply is received, the MGW shall consider the (G)MSC to have failed. The 
MGW may then attempt to recontact its controlling (G)MSC by performing MGW Communication UP. If not 
successful, the MGW may then attempt to register to a new (G)MSC. 

10.16 Hanging termination detection 

Whenever requesting new ephemeral bearer terminations, the (G)MSC shall request the MGW to periodically report 
termination heartbeat indications to detect hanging context and termination in the MGW that may result e.g. from a loss 
of communication between the MSC-S and the MGW. This may also be done when requesting TDM terminations, 
though alternative means exist for the (G)MSC to detect hanging TDM terminations, e.g. via receipt of the error #433 
when seizing the termination. 

When the (G)MSC server receives a termination heartbeat notification from the MGW via the Termination heartbeat - 
Indication procedure, the (G)MSC shall return a Termination heartbeat -Indication Ack (without an error) if the context 
id / termination identity combination exists in the (G)MSC. If it does not exist, the (G)MSC shall return an error and 
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shall correct the mismatch, e.g. by requesting the MGW to subtract the indicated termination and to clear any associated 
context. 



(G)MSGS 



MGW 



Termination heartbeat 
- Indication 



Termination heartbeat 
- Indication Aek . 



Figure 10.16.1 : Termination heartbeat - Indication 



11 



Identities 



11.1 Bearer Address and Binding Reference 

The Bearer Address is exchanged on the Nc and Mc interfaces to identify the termination point of the bearer control 
signalUng within the peer Media Gateway. 

A Binding Reference is an identity, unique within the scope of one bearer control function, which identifies a bearer 
network connection. This information is exchanged on the Nc and Mc interfaces. The bearer control function is 
identified by the Bearer Address. 

11.2 IVIGW-ld 

The Media Gateway Identity (MGW-Id) is information sent on the Nc interface to aid Media Gateway selection by the 
succeeding/preceding node. 

The MGW-Id is bearer independent and it can be translated into a signalling address towards the appropriate MGW. 



1 1 .3 (G)I\/ISC server Address 



The (G)MSC server Address defines the signalling address associated with the (G)MSC server that is used to interact 
with the Media Gateway over the Mc interface. This is a unique address in the network service suppUer domain. 



1 2 Operational Aspects 
12.1 Charging 

No impacts. 

1 3 Interactions with Other Services 

NOTE 1: All message sequence charts in this clause are informative examples. 
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NOTE 2: The continuity indication in the lAM is not used to indicate that a continuity check will be performed on 
the current leg of the call, but it is used to indicate that a Continuity message can be expected as a result 
of a continuity check on a preceding ISUP circuit, or establishment of a preceding bearer coimection. 

13.1 Enhanced Multi- Level Precedence and Pre-emption service 
(elVILPP) 

No impact. 



13.2 Call Deflection Service 

The procedures specified in 3GPP TS 23.072 [9] for the Call Deflection supplementary service shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. 

1 3.2.1 IVIGW selection and incoming side bearer establisliment 

The MGW selected for the mobile terminating call is used. The incoming side bearer has already been estabUshed by 
the mobile terminating call procedures. 

13.2.2 I U/A-interface release 

If the call deflection request from a served subscriber is accepted the call towards the served mobile subscriber shall be 
released as described in the clause for call clearing. 

1 3.2.3 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calhng party. If the notification is implemented using intermediate tones or 
announcements the MSG server requests the MGW to play an announcement/tone to the calling party, as described in 
clause 14.6, before establishing the call to the forwarded-to subscriber. 

13.2.4 Initial addressing 

The call towards the deflected-to subscriber is estabhshed as for basic call. If out-of-band transcoder control is applied 
for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. After the possible generation of in-band 
information has been completed the MSG server shall indicate in the lAM that forward or backward bearer 
estabhshment is to be used. The MSG server shall indicate in the lAM that no Continuity message will follow since the 
incoming bearer has already been established. 

The MGW-id can be provided to the succeeding node in the lAM. 

1 3.2.5 Establishment of bearer towards the fonwarded-to subscriber 

The bearer establishment towards the forwarded-to subscriber is performed as described for the mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The MSG server also 
requests the MGW to both- way through-connect the bearer. 

13.2.6 Failure handling in MSC server 

The failures are handled as described for the basic mobile originating call. 

13.2.7 Example 

Figure 13.1 shows the network model for call deflection. The "squared" line represents the call control signalling. The 
"dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access case there is no 
separation of call and bearer control signalling. The MSC server replaces the bearer termination for the served mobile 
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subscriber (Tb) with the bearer termination for the deflected-to subscriber (Tc) in an existing context in the MGW. The 
bearer termination Ta is used for the bearer towards the preceding MGW (calling subscriber). 



Before CD: 



After CD: 




^ CTXab ^ ^JRNC/BSCr 




Figure 13.1 : Call deflection (Network model) 

Figure 13.2 shows the message sequence example for the call deflection with a possible notification to the calling party 
using an announcement. In the example, after the call and the bearer towards the access side have been released the 
MSC server requests the MGW to remove the bearer termination for the served mobile subscriber, and optionally 
requests the MGW to play an announcement and to notify the announcement completion. The MSC server shall request 
the establishment of the call towards the deflected-to subscriber after the possible announcement has completed. 



MSC-S 



MGW 



RNC/BSC 



UE 



Mobile terminating call and bearer establishment 



Context (Cab) 
Context (Cab) 



CaU F*rogress 



Call 



Call 



Deflection req 



Deflection ack 



Call and bearer release 



SUB. request (Tb 



SUB.reply (1b) 



OFl: Y 



Play 
announce 
ment 

(Ta) 



Outgoing call and bearer establishment 



NOTE: ORl: Notification to calling subscriber required (Y:yes N:no) 

Figure 13.2: Call deflection (message sequence chart) 
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13.3 Line identification Services 



13.3.1 Calling Line Identification Presentation (CLIP) 

No impact. 

13.3.2 Calling Line Identification Restriction (CLIR) 

No impact. 

13.3.3 Connected Line Identification Presentation (COLP) 

No impact. 

13.3.4 Connected Line Identification Restriction (COLR) 

No impact. 



13.4 Call Forwarding Services 

13.4.1 Call Forwarding Unconditional (CFU) 

The procedures specified in 3GPP TS 23.082 [12] for the Call Forwarding Unconditional supplementary service shall 
be followed. The following clauses describe the additional requirements for the bearer independent CS core network. 



13.4.1.1 MGW selection 

If in-band information is to be provided to the calling subscriber the GMSC server shall select the MGW before 
providing the in-band information. The MGW selection can be based on a possibly received MGW-Id from the 
preceding node. 

If in-band information is to not to be provided to the calUng subscriber the GMSC server shall select the MGW for the 
bearer as described for the basic mobile terminating call. 



1 3.4.1 .2 Incoming side bearer establishment 

The incoming side bearer establishment is handled in the GMSC server as described for the mobile terminating call 
using either forward or backward bearer establishment. 



1 3.4. 1 .3 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. If the notification is implemented using intermediate tones or 
announcements the GMSC server requests the MGW to play an announcement/tone to the calling party, as described in 
clause 14.6, before establishing the call to the forwarded-to subscriber. 



13.4.1.4 Initial addressing 

If the incoming call is to be forwarded without being offered to the served mobile subscriber the call towards the 
forwarded-to subscriber is established as for a basic call. If out-of-band transcoder control is applied for a speech call, it 
shall be performed in accordance with 3GPP TS 23.153 [3]. After the possible generation of in-band information has 
been completed the initial addressing towards the forwarded-to subscriber is performed as described for the basic 
mobile terminating call indicating either forward or backward bearer estabUshment. 
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13.4.1 .5 Establishment of bearer towards the forwarded-to subscriber 

The bearer establishment towards the forwarded-to subscriber is performed as described for the mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The GMSC server also 
requests the MGW to both-way through-connect the bearer. 

1 3.4.1 .6 Confirmation of bearer establishment 

The confirmation of the bearer establishment is handled as described for the basic mobile terminating call. 

1 3.4.1 .7 Failure handling in GMSC server 

The failures are handled as described for the basic mobile terminating call. 

13.4.1.8 Example 

Figure 13.3 shows the network model for call forwarding unconditional. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling and the bearer. The GMSC server seizes one 
context with two bearer terminations in the MGW. The bearer termination T^ is used for the bearer towards the 
preceding MGW (calling subscriber) and the bearer termination Tc is used for the bearer towards the succeeding MGW 
(forwarded-to subscriber). 



Before CFU: After CPU: 




Figure 13.3: CFU (Network model) 



Figure 13.4 shows the message sequence example for the call forwarding unconditional with a possible notification to 
the calling party using an announcement. In the example the GMSC server optionally requests the MGW to play an 
announcement and to notify the announcement completion, after the bearer to the incoming side has been established. 
When the possible announcement has completed the GMSC server requests the establishment of the call and the bearer 
towards the forward-to subscriber. 
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GMSC-S 



MGW 



Incoming call and bearer establishment 



1 — r 



HLR interrogation 



Address Complete 



Play 
Announce 
ment 

(Ta) 



Outgoing call and bearer establishment 



Figure 13.4: CFU (message sequence chart) 

13.4.2 Call Forwarding on mobile subscriber Busy (CFB) 

The procedures specified in 3GPP TS 23.082 [12] for the Call Forwarding on Busy supplementary service shall be 
followed. The following clauses describe the additional requirements for the bearer independent CS core network. 



13.4.2.1 



Network Determined User Busy (NDUB) 



If the mobile is Network Determined User Busy the incoming call for the specified basic service(s) shall be forwarded 
without being offered to the served mobile subscriber. 



13.4.2.1.1 



MGW selection 



The MSC server shall select an MGW for the bearer connection either before sending the lAM or after receiving the 
Bearer Information message. If the MSC server received an MGW-id from the preceding node and/or from the 
succeeding node, then it may use one of them for the MGW selection. 

If in-band information is to be provided to the calling subscriber the MSC server shall select the MGW before providing 
the in-band information. The MGW selection can be based on a possibly received MGW-Id from the preceding node. 

NOTE: As an implementation option, if there is no need for the MSC server to manipulate the bearer, the MSC 
server may only perform call control signalling without any associated MGW. In that case the bearer 
related information shall be provided transparently through the MSC server. 



13.4.2.1.2 



Incoming side bearer establishment 



The incoming side bearer establishment is handled in the MSC server as described for the mobile terminating call using 
either forward or backward bearer establishment. The incoming side bearer establishment can take place either before or 
after the detection of NDUB condition. 



13.4.2.1.3 



Notification to the calling subscriber 



If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. If the notification is implemented using intermediate tones or 
announcements the MSC server requests the MGW to play an announcement/tone to the calling party, as described in 
clause 14.6, before establishing the call to the forwarded-to subscriber. 
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13.4.2.1.4 Initial addressing 

The call towards the forwarded-to subscriber is established as for basic call. If out-of-band transcoder control is applied 
for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. In-band information may be played to 
the calling subscriber. 

If no in-band information is to be played to the calling subscriber, in order to withhold the call completion until the 
establishment of the bearer is complete. 

The MSG server shall indicate in the lAM that the Continuity message will follow from the preceding node if either of 
the following conditions is satisfied before sending the lAM: 

1 . The incoming JAM indicated that the Continuity message will follow, but no Continuity message has been 
received, or 

2. The incoming side bearer has not been estabUshed. 

If the MGW is selected at an early stage the MGW-id can be provided to the succeeding node in the lAM. 

13.4.2.1 .5 Establishment of bearer towards the forwarded-to subscriber 

The bearer establishment towards the forwarded-to subscriber is performed as described for mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The MSC server also 
requests the MGW to both-way through-coimect the bearer. 

1 3.4.2.1 .5 Confirmation of bearer establishment 

If the outgoing lAM indicated that the Continuity message will follow, the Continuity message is sent when both of the 
following conditions are satisfied: 

1. Either: 

a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received, or 

b. The incoming lAM indicated that no Continuity message will follow. 

2. Either: 

a. The MSC server has selected an MGW, and a notification indicating successful completion of the incoming 
side bearer set-up has been received from the MGW using the Bearer EstabUshed procedure, or 

b. MGW selection is not required for this call. 

1 3.4.2.1 .6 Failure handling in MSC server 

The failures are handled as described for the basic mobile originating call. 

13.4.2.1.7 Example 

Figure 13.5 shows the network model for call forwarding busy (network determined user busy). The "squared" line 
represents the call control signalling. The "dotted" line represents the bearer control signalling and the bearer. The MSC 
server seizes one context with two bearer terminations in the MGW. The bearer termination Ta is used for the bearer 
towards the preceding MGW (calhng subscriber) and the bearer termination Tc is used for the bearer towards the 
succeeding MGW (forwarded-to subscriber). 
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Before CFB (NDUB): 



After CFB (NDUB): 





Figure 13.5: CFB; NDUB (Network model) 

Figure 13.6 shows the message sequence example for the call forwarding busy (network determined user busy) using a 
possible announcement. In the example the MSC server optionally requests the MGW to play an announcement and to 
notify the announcement completion, after the bearer to the incoming side has been established. When the possible 
announcement has been completed the MSC server requests the establishment of the call towards the forward-to 
subscriber. 



MSC-S 




MGW 




RNC/ 




UE 










BSC 







Incoming Call and Bearer Establishment 



NDUB 



Address Complete 



Play 
Announce 
ment 

(Ta) 



CRl: Y 



Notification 



Outgoing Call and Bearer Establishment 

~n \ 



1 r 



1 r 



NOTE: ORl : Notification to forwarding subscriber required (Y: yes N: no) 
NDUB: Network Determined User Busy 

Figure 13.6: CFB (NDUB) 

1 3.4.2.2 User Determined User Busy (UDUB) 
13.4.2.2.1 MGW selection 

The MGW selected for the mobile terminating call is used, if already selected by the mobile terminating call 
procedures. 
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The MSG server selects an MGW for the bearer either before sending the lAM of after receiving the Bearer Information 
message. If the MSG server received an IVIGW-id from the preceding node and/or from the succeeding node, then it 
may use one of them for the MGW selection. 

If in-band information is to be provided to the calling subscriber the MSG server shall select the MGW before providing 
the in-band information. The MGW selection can be based on a possibly received MGW-Id from the preceding node. 

NOTE: As an implementation option, if there is no need for the MSG server to manipulate the bearer, the MSG 
server may only perform call control signalling without any associated MGW. In that case the bearer 
related information shall be provided transparently through the MSG server. 

13.4.2.2.2 Incoming side bearer establisliment 

For bearer establishment, the sending of bearer information is handled in the MSG server as described for the basic 
mobile terminating call indicating either forward or backward bearer establishment. The incoming side bearer 
estabUshment can take place either before or after the detection of UDUB condition. 

13.4.2.2.3 I U/A-interf ace release 

If the mobile is not Network Determined User Busy (NDUB as defined in GSM TS 02.01) the incoming call is offered 
(as a normal or waiting call) to the served mobile subscriber. If the mobile indicating "User Busy" subsequently releases 
the call, the call towards the served mobile subscriber is released as described in the clause for call clearing. 

NOTE: The MSG server orders the MGW to remove the bearer termination towards the served mobile subscriber only 
in the case where the radio resources had already been allocated in the MGW (bullet 1 in figure 13.8). 

1 3.4.2.2.4 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. If the notification is implemented using intermediate tones or 
announcements the MSG server requests the MGW to play an announcement/tone to the calling party as described in 
clause 14.6 before estabhshing the call to the forwarded-to subscriber. 

13.4.2.2.5 Initial addressing 

The call towards the forwarded-to subscriber is established as basic call. If out-of-band transcoder control is applied for 
a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. In-band information may be played to the 
calling subscriber. 

If no in-band information is to be played to the calling subscriber, in order to withhold the call completion until the 
establishment of the bearer is complete. The MSG server shall indicate in the lAM that the Gontinuity message will 
follow from the preceding node if either of the following conditions is satisfied before sending the lAM: 

1 . The incoming lAM indicated that the Gontinuity message will follow, but no Gontinuity message has been 
received, or 

2. The incoming side bearer has not been estabUshed. 

If the MGW is selected at an early stage the MGW-id can be provided to the succeeding node in the lAM. 

1 3.4.2.2.6 Establishment of bearer towards the forwarded-to subscriber 

The bearer estabhshment towards the forwarded-to subscriber is performed as described for the mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The MSG server also 
requests the MGW to both-way through-coimect the bearer. 

1 3.4.2.2.7 Confirmation of bearer establishment 

If the outgoing lAM indicated that the Gontinuity message will follow, the Gontinuity message is sent when both of the 
following conditions are satisfied: 

1. Either: 
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a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received from the preceding node (bullet 8 in figure 6.6), or 

b. The incoming lAM indicated that no Continuity message will follow; 
2. Either: 



a. The MSC server has selected an MGW, and a notification of successful bearer establishment in the incoming 
side has been received from the MGW (bullet 7 in figure 6.6), or 

b. MGW selection is not required for this call. 



13.4.2.2.8 Failure handling in MSC server 

The failures are handled as described for the basic mobile originating call. 



13.4.2.2.9 



Example 



Figure 13.7 shows the network model for call forwarding busy (user determined user busy). The "squared" line 
represents the call control signalling. The "dotted" line represents the bearer control signalling and the bearer. Note that 
for a TDM access case there is no separation of call and bearer signalling. The MSC server replaces the bearer 
termination for the served mobile subscriber (Tb) with the bearer termination for the forwarded-to subscriber (Tc) in an 
existing context in the MGW. The bearer termination Ta is used for the bearer towards the preceding MGW (calling 
subscriber). 



Before CFB (UDUB): 



After CFB (UDUB): 



MSC-S 




^ CTXab ^ ^NC/BSCr 



MGW 




Figure 13.7: CFB; UDUB (Network model) 



Figure 13.8 shows the message sequence example for the call forwarding busy (user determined user busy) with a 
possible notification to the calling party using an announcement. In the example, after the call and the bearer towards 
the access have been released the MSC server requests the MGW to remove the bearer termination for the served 
mobile subscriber, optionally requests the MGW to play an announcement and to notify the announcement completion. 
After the possible announcement has been completed the MSC server requests the establishment of the call towards the 
forward-to subscriber. 
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Figure 13.8: CFB (UDUB) 



1 3.4.3 Call Forwarding on No Reply (CFNRy) 

The procedures specified in 3GPP TS 23.082 [12] for the Call Forwarding on No Reply supplementary service shall be 
followed. The following clauses describe the additional requirements for the bearer independent CS core network. 



13.4.3.1 MGW selection and incoming side bearer establishment 

The MGW selected for the mobile terminating call is used. The incoming side bearer has already been estabUshed by 
the mobile terminating call procedures. 



13.4.3.2 I U/A-interface release 

If the call is not answered within the period defined by the no reply condition timer the call towards the served mobile 
subscriber will be released as described in the clause for call clearing. 



1 3.4.3.3 Notification to the Calling Subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. If the notification is implemented using intermediate tones or 
announcements the MSC server requests the MGW to play an announcement/tone to the calling party, as described in 
clause 14.6, before establishing the call to the forwarded-to subscriber. 
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13.4.3.4 Initial addressing 

The call towards the forwarded-to subscriber is established as a basic call. If out-of-band transcoder control is applied 
for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. After the possible generation of in-band 
information has been completed (bullet 2 in figure 13.10) the MSG server shall indicate in the lAM that no Continuity 
message will follow from the preceding node because the incoming side bearer has already been established. 

The MGW-id can be provided to the succeeding node in the lAM. 



1 3.4.3.5 Establishment of bearer towards the forwarded-to subscriber 

The bearer establishment towards the forwarded-to subscriber is performed as described for the mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The MSC server also 
requests the MGW to both-way through-connect the bearer. 



13.4.3.6 Failure handling in MSC server 

The failures are handled as described for the basic mobile originating call. 



13.4.3.7 Example 

Figure 13.9 shows the network model for call forwarding no reply. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access case 
there is no separation of call and bearer control signalling. The MSC server replaces the bearer termination for the 
served mobile subscriber (Tb) with the bearer termination for the forwarded-to subscriber (Tc) in an existing context in 
the MGW. The bearer termination T^ is used for the bearer towards the preceding MGW (calling subscriber). 



Before CFNRy: 



After CFNRy: 





Figure 13.9: CFNRy (Network model) 



Figure 13.10 shows the message sequence example for the call forwarding on no reply with a possible announcement. 
In the example, after the call and the bearer towards the access have been released the MSC server requests the MGW 
to remove the bearer termination for the served mobile subscriber, and optionally requests the MGW to play an 
announcement and to notify the announcement completion. When the possible announcement has been completed the 
MSC server requests the establishment of the call towards the forward-to subscriber. 
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Figure 13.10: CFNRy (message sequence chart) 

13.4.4 Call Forwarding on mobile subscriber Not Reachable (CFNRc) 

The procedures specified in 3GPP TS 23.082 [12] for the Call Forwarding on Not Reachable supplementary service 
shall be followed. The following clauses describe the additional requirements for the bearer independent CS core 
network. 

13.4.4.1 Rerouting by HLR 

The same handling as for Call Forwarding Unconditional applies. 

1 3.4.4.2 Rerouting by VLR 

If the mobile is not reachable the incoming call for the specified basic service(s) wiU be forwarded without being 
offered to the served mobile subscriber. 
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13.4.4.2.1 MGW selection 

If in-band information is to be provided to the calling subscriber the MSC server shall select the MGW before providing 
the in-band information. The MGW selection can be based on a possibly received MGW-Id from the preceding node. 

NOTE: As an implementation option, if in-band information is not to be provided to the calling subscriber the 
MSC server may either perform call control without any associated MGW, or reserve resources from an 
MGW and request bearer establishment through that MGW. In the latter case the MSC server selects an 
MGW for the bearer either before sending the lAM or after receiving the Bearer Information message. If 
the MSC server received an MGW-Id from the preceding node and/or from the succeeding node, those 
can be used for the MGW selection. 

1 3.4.4.2.2 Incoming side bearer establishment 

The incoming side bearer establishment is handled in the MSC server as described for the mobile terminating call, using 
either forward or backward bearer establishment. The incoming side bearer establishment can take place either before or 
after the detection of the not reachable condition. 

1 3.4.4.2.3 Notification to the calling subscriber 

If the served mobile subscriber has requested that the calling subscriber shall receive a notification about the call 
forwarding, a notification is sent to the calling party. If the notification is implemented using intermediate tones or 
announcements the MSC server requests the MGW to play an announcement/tone to the calling party, as described in 
clause 14.6, before establishing the call towards the forwarded-to party. 

13.4.4.2.4 Initial addressing 

The call towards the forwarded-to subscriber is established as a basic call. If out-of-band transcoder control is applied 
for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. In-band information may be played to 
the calling subscriber. 

If no in-band information is to be played to the calling subscriber, in order to withhold the call completion until the 
establishment of the bearer is complete the MSC server shall indicate in the lAM that the Continuity message wiU 
foUow from the preceding node, if either of the following conditions is satisfied before sending the lAM: 

1 . The incoming lAM indicated that the Continuity message will follow, but no Continuity message has been 
received, or 

2. The incoming side bearer has not been established. 

If the MGW is selected at an early stage the MGW-id can be provided to the succeeding node in the lAM. 

1 3.4.4.2.5 Establishment of bearer towards the forwarded-to subscriber 

The bearer establishment towards the forwarded-to subscriber is performed as described for mobile originating call, 
network side bearer establishment, using either forward or backward bearer establishment. The MSC server also 
requests the MGW to both-way through-connect the bearer. 
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13.4.4.2.6 Confirmation of bearer establishment 

If the outgoing lAM indicated that a Continuity message will follow, the Continuity message shall be sent when both of 
the following conditions are satisfied: 

1. Either: 



a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received, or 

b. The incoming lAM indicated that no Continuity message will follow. 
2. Either: 



a. The MSC server has selected an MGW, and a notification indicating successful completion of the incoming 
side bearer set-up has been received from the MGW using the Bearer Established procedure, or 

b. MGW selection is not required for this call. 



13.4.4.2.7 Failure handling in MSC server 

The failures are handled as described for the basic mobile originating call. 



13.4.4.2.8 



Example 



Figure 13.11 shows the network model for call forwarding on not reachable. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer control signalling and the bearer. The MSC server seizes one 
context with two bearer terminations in the MGW. The bearer termination Ta is used for the bearer towards the 
preceding MGW (calhng subscriber) and the bearer termination Tc is used for the bearer towards the succeeding MGW 
(forwarded-to subscriber). 



Before CFNRc: 



After CFNRc: 





Figure 13.11: CFNRc; Rerouting by VLR (Networl< model) 



Figure 13.12 shows the message sequence example for the call forwarding on not reachable with a possible 
announcement. In the example the MSC server optionally requests the MGW to play an announcement and to notify the 
announcement completion, after the bearer to the incoming side has been established. When the possible announcement 
has been completed the MSC server requests the establishment of the call towards the forward-to subscriber. 
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Figure 13.12: CFNRc (Rerouting by VLR) (message sequence chart) 



13.5 Call Waiting (CW) 

The procedures specified in 3GPP TS 23.083 [13] for the Call Waiting supplementary service shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. The following 
clauses assume subscriber A to be the served subscriber with the call waiting supplementary service, subscriber B to be 
the one who is engaged in a call with user A, subscriber C to be the one who has originated a call to subscriber A which 
causes the call waiting supplementary service to be invoked. 

Call confirmation to the waiting call 

The MSC server shall, on reception of the call confirmation, select the MOW that will be used for the waiting call. The 
MSC server should select the MOW which is akeady in use for the active call. If out-of-band transcoder control is 
applied for the waiting speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 

Existing call on hold 

The clause "Hold request" in clause 13.6 applies. 
Existing call released 

If the active call is disconnected while another call is waiting, the bearer termination towards the waiting party (C) as 
well as to the called party (A) is not removed. 

Acceptance of waiting call 

If the mobile subscriber decides to accept the waiting call, it handles (according to 3GPP TS 23.083 [13]) the existing 
call as described in clause 13.5 (i.e. it either puts the call on hold or the call is released). When the MSC server receives 
the connect indication from subscriber A, if required the MSC server shall modify the access bearer as described in 
subclause 13.18.1. Finally, the MSC server shall connect the access side bearer termination to the previously created 
bearer termination of the remote party in the waiting call and modify the waiting call's bearer termination so that it is 
both-way through-connected. 

If a different MOW is selected for the incoming call, then a bearer from the new MOW (MGW2) shall be connected 
towards the old MGW (MGWl) before offering the call to the subscriber A. 
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If out-of-band transcoder control is applied for the waiting speech call, it shall be performed in accordance with 
3GPP TS 23.153[3]. 

Waiting call released by calling subscriber (subscriber C) 

The respective resources already allocated at the selected MGW for the waiting call shall be released. 
Example 

Figure 13.13 shows the network model for a waiting call at the serving MSG server/MGW. The "thick, squared" line 
represents the call control signalling for the existing call and, on the lu interface, the already existing control plane 
toward the serving RNC. The "thin, squared" line represents the call control signalling for the waiting call. The "thick, 
dotted" line represents the bearer control signalling and the bearer for the existing call, whereas the "thin, dotted" line 
represents the ones for the waiting call. Note that for a TDM access there is no separation of call and bearer control 
signalling. 

NOTE: There shall be only one instance of bearer resource/bearer control signalling on the radio side. 

If the CW condition applies, the MSG server seizes a new context with one bearer termination, Tc, in the MGW. Ta and 
Tb are the terminations of the already existing call. 




Figure 13.13: Call Wait (network model) 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



156 



ETSI TS 123 205 V9.2.0 (2011-04) 



1 3.5.1 Call Confirmation of the waiting call 

Figure 13. 14 shows the sequence chart for the actions necessary within the bearer independent CS core network during 
call confirmation of the waiting call. Call and bearer establishment shall be as described for the mobile terminating call. 
When the MSC server receives the Alerting indication from the called subscriber (subscriber A), it shall apply the 
ringing tone to the waiting termination (Tc). 
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Figure 13.14: Call Confirmation of the Waiting Call. 
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1 3.5.2 Acceptance of the Waiting Call 

Figure 13.15 shows the sequence chart for the actions necessary within the bearer independent CS core network for the 
acceptance of a waiting call. When the MSC server receives the Connect indication from the UE (subscriber A) (bullet 
1 in figure 13.15), it shall request the MGW to disconnect subscriber C from the applied ringing tone (bullet 2 in 
figure 13.15) and move Ta to the context of the waiting call (bullet 3 in figure 13.15). The MSC server then requests the 
MGW to change the through-connection of the termination Tc so that it will be both way through-connected (bullet 4 in 
figure 13.15). 
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Figure 13.15: Acceptance of the Waiting Call. 



13.6 Call Hold (CH) 

The procedures specified in 3GPP TS 23.083 [13] for the Call Hold supplementary service shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. 

13.6.1 Hold request 

When the UE makes a request for the hold function the MSC server requests the MGW to interrupt the communication 
on the bearer by changing the through-connection of the bearer termination towards the served mobile subscriber to 
"not through-connected" or by using the Isolate Bearer Termination Procedure. Announcements may be applied to the 
held party as described in clause 14.6. 
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1 3.6.2 Retrieval request 

When the UE makes a request to retrieve a held call the MSC server requests the MGW to re-establish communication 
to the held party by changing the through-connection of the bearer termination towards the served mobile subscriber to 
be both-way through-connected or by using the Join Bearer Termination Procedure. 

1 3.6.3 Setting up another call 

The call towards the C party is established as described for the mobile originating call. A new MGW may be selected in 
the course of setting up the new call. If out-of-band transcoder control is applied for a speech call, it shall be performed 
in accordance with 3GPP TS 23.153 [3]. If required, the MSC server shall modify the access bearer for the new call as 
described in subclause 13.18.1. The MSC server will request the MGW to cormect the access side bearer termination to 
the bearer termination of the remote party. 

1 3.6.4 Alternate from one call to the other 

When the hold request for the active call is immediately followed by a retrieve request for the held call the MSC server 
shall request the MGW to connect the bearer termination of the served mobile subscriber to the bearer termination of 
the held party. The MSC server also requests the MGW to both-way through-cormect the bearer for the previously held 
call. 

13.6.5 Disconnect 

If the active call is disconnected while another call is on hold, the bearer termination towards the served mobile 
subscriber is not removed but the call towards the active party is discoimected as described in the clause for call 
clearing. 

If the held call is disconnected while the served mobile subscriber is connected to an active call the bearer termination 
towards the served mobile subscriber shall not be removed but the call towards the held party is disconnected as 
described in the clause for call clearing. 

13.6.6 Failure handling in MSC server 

If any procedure between the MSC server and the MGW has not completed successfully, the MSC server shall reject 
the hold/retrieve request. 

13.6.7 Example 1 

Figure 13.16 shows the network model for the call hold with an establishment of a new call. The "squared" line 
represents the call control signalhng. The "dotted" hne represents the bearer control signalling and the bearer. The MSC 
server isolates the flow connection between the served mobile and the termination in the MGW that is used for the held 
call. If an announcement is to be played to the held party the MSC Server may seize a new context in the MGW. If a 
new call is made to C subscriber the MSC server seizes a new context in the MGW if not previously done. The new 
context is used for the new call and the old context is used for the held call. The bearer termination Ta is moved with 
the bearer towards the RNC (served mobile subscriber) and the bearer termination Tc is used for the bearer towards the 
succeeding MGW (C-party). 

NOTE: The main advantage with example 1 is that if B party is connected to a radio access and a handover 
occurs then the announcement termination is unaffected and therefore there is no break in the 
announcement. It is also an option to put the B -party on hold using the isolate bearer procedure 
immediately but this is not shown in this example. 
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I party on hold: j^^^ q subscriber/Announcement to B party: 




Figure 13.16: Call hold and establishment of a new call (Network model) example 1 

Figure 13.17 shows the message sequence for example 1 for the call hold procedure. In the example the MSC server 
requests the MGW to change the through-connection of the bearer so that it will not be through-connected when the 
hold request is received from the served mobile subscriber (bullet 2 in figure 13.17). Subsequently if an announcement 
is to be applied then Termination Ta may be isolated from the held party (bullet 3 in figure 13.17) and a new 
announcement termination TA2is added to context CTXab and announcement applied to termination Ta2 (bullet 3 a in 
figure 13.17). For setting up a new call to the C-party the termination Ta is moved to a new context if not done 
previously (bullet 4 in figure 13.17) and a new termination Tc is reserved (bullet 5 in figure 13.17) and the call shall 
continue with the appropriate stream mode settings as for a normal call estabUshment in accordance with Clause 6.1, 
see figure 6.2. 
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Figure 13.17: Hold request (message sequence chart) , example 1 

Figure 13.18 shows the message sequence for example 1 for the retrieval procedure. In the example the MSC server 
requests the MGW to move the connection of the bearer back to be both-way through-connected (bullet 3 and 4 in 
figure 13.18) to the held party, after the held party has been disconnected from an optionally applied announcement 
(bullet 2 in figure 13.18). The MOVE command (Join Bearer termination procedure) is not required (bullet 3 in figure 
13. 18) if Ta has not previously been moved into the CTXac. The Change Through-Connection is only required if the 
retrieval occurs prior to any connection to C-party. 
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Figure 13.18: Retrieval request (message sequence chart) , example 1 

13.6.8 Example 2 

Figure 13.18a shows the network model for the call hold with an establishment of a new call. The "squared" line 
represents the call control signalling. The "dotted" line represents the bearer control signalling and the bearer. The MSC 
server isolates the flow connection between the served mobile and the termination in the MGW that is used for the held 
call. After the request to establish a new call is made the MSC server seizes a new context in the MGW, the new 
context is used for the new call and the old context is used for the held call. The bearer termination Ta for the bearer 
towards the RNC (served mobile subscriber) is moved to this context and the bearer termination Tc is used for the 
bearer towards the succeeding MGW (C -party). In this example the announcement is played directly to Termination Tb. 



NOTE: if B party is connected to a radio access and a handover occurs during the announcement then the 
announcement will be interrupted. It is also possible to put B-party on hold using the isolate bearer 
termination but if the announcement is still played directly to termination Tb as proposed by this example 
and a handover occurs then the problem still arises. 
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B-party on hold/announcement played; ^ew call to C subscriber: 




Figure 13.18a: Call hold and establishment of a new call (Network model) example 2 

Figure 13. 18b shows the message sequence for example 2 for the call hold procedure. In the example the MSC server 
requests the MGW to change the through-connection of the bearer to inactive when the hold request is received from 
the served mobile subscriber (bullet 2 in figure 13.18b). Subsequently an announcement may be applied to termination 
Tb (bullet 3 in figure 13.18b). Then the new call is established via a new context with served mobile subscriber 
termination Ta being moved to this new context (bullet 4 in figure 13.18b) and a new termination Tc is reserved (bullet 
5 in figure 13.18b) and the call shall continue with the appropriate stream mode settings as for a normal call 
establishment in accordance with Clause 6.1, see figure 6.2. 
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Figure 13.18b: Hold request (message sequence chart), example 2 

Figure 13.18c shows the message sequence example for the retrieval procedure. In the example the MSC server moves 
the served mobile subscriber back to the context with termination Tb and requests the MGW to change the through- 
connection of the bearer to be both-way through-connected (bullet 3 and 4 in figure 13.18c) after the held party has 
been disconnected from an optionally applied announcement (bullet 2 in figure 13.18c). The MOVE command (Join 
Bearer Termination procedure) is not required (bullet 3 in figure 13.18c) if Ta has not been in the CTXac. The Change 
Through-Connection is only required if the retrieval occurs prior to any connection to C-party. 
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Figure 13.18c: Retrieval request (message sequence chart), example 2 



13.7 Multiparty (MPTY) 

The procedures specified in 3GPP TS 23.084 [14] for the Multi Party supplementary service shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. If out-of-band 
transcoder control is applied for the call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 

1 3.7.1 Beginning tine Multi Party call 

When the served mobile subscriber invokes a Multi Party service the MSG server selects an MGW that provides the 
Multi Party bridge capabilities. If the selected MGW is different from the MGW that is used for the active call, the 
MSG server requests the MGW(s) to connect the bearer terminations of the participants to the selected MGW. The 
bearer terminations are connected together. 

1 3.7.2 Managing an active Multi Party call 

When the served mobile subscriber puts the Multi Party call on hold the MSG server requests the MGW to interrupt the 
connection between the served mobile subscriber and the Multi Party bridge. 

When the served mobile subscriber retrieves a held Multi Party call the MSG server requests the MGW to re-establish 
the connection between the served mobile subscriber and the Multi Party bridge. 

When the served mobile subscriber requests private communication with one of the remote parties (e.g. B-party), the 
MSG server shall request the MGW to interrupt the connection between the served mobile subscriber and the Multi 
Party bridge, and connection between the remote B party and the Multi Party bridge. The MSG server requests the 
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MGW to connect the bearer termination of the served mobile subscriber to the bearer termination of the remote party 
(or vice versa) within a same context. 

13.7.3 Disconnect 

If a remote party is disconnected while other parties still remain the call towards the remote party is disconnected as 
described in the clause for call clearing. 

13.7.4 Failure Inandling in MSG server 

If resources for the Multi Party service cannot be allocated in any of the MGW resources assigned to the MSG server, 
then the MSG server shall reject the MPTY request. 

13.7.5 Example 1 - Multiparty call establishment 

Figure 13.19 shows the network model for multi party call. The "squared" line represents the call control signalling. The 
"dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access there is no separation 
between the call and bearer control signalling. In the following example it is assumed that each party participating in the 
Multi Party conference is handled in a separate context representing the call leg between the Multi Party bridge and the 
Multi Party participant. The Multi Party bridge itself is handled in a separate context. This separation to several contexts 
is done in order to simplify interactions with other functionality, such as handover, even though other implementation 
options are not excluded. 




Figure 13.19: Multi Party call (Network model) 

For the purposes of the information flow diagrams it is assumed that there are only two remote parties. Party A is the 
subscriber controlling the Multi Party service (served mobile subscriber). Party B is the held party and party G is the 
active party. 

It is assumed that the Multi Party bridge is located in the MGW that has been selected for the served mobile subscriber. 

Figure 13.20 shows the message sequence example for the beginning of multi party call. When the served mobile 
subscriber invokes a Multi Party service the MSG server requests the MGW to create a separate context for the Multi 
Party bridge. The MSG server seizes a bearer termination for each party in that context. In addition, each call leg is 
represented by a separate context. Therefore the parties in the active call will be split in separate contexts. The MSG 
server requests the MGW to create a new context and to move the bearer termination for the served mobile subscriber 
from the active call context to the new context. To connect the parties to the Multi Party bridge the MSG server requests 
the MGW to establish internal Nb connections between the bearer terminations in the Multi Party bridge context and the 
call leg contexts, using the standard external bearer setup procedures. The held party is informed about the retrieval of 
the held call, and the both remote parties are informed about the multi party call establishment. 
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Figure 13.20: Information flow for multi party call, internal ATM bearer (message sequence chart) 
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Figure 13.20a: Information flow for multi party call, internal IP bearer (message sequence chart) 

1 3.7.6 Example 2 - Private call establishment during multiparty call 

Figure 13.20b shows the network model for private call. The "squared" line represents the call control signalling. The 
"dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access there is no separation 
between the call and bearer control signalling. 
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Figure 13.20b: Private call (Network model) 
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Figure 13.20c: Information flow for private call (message sequence chart) 

NOTE: The two MOVE commands may be sent in different transactions. 

For the purposes of the information flow diagrams it is assumed that there are only two remote parties and the private 
call is established between the served mobile subscriber (Party A) and the remote C-party. 

Figure 13.20c shows the message sequence example for the beginning of private communication between the served 
mobile subscriber and the remote parties (e.g. C-party). 
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1 3.8 Closed User Group (CUG) 

No impact. 

1 3.9 Advice of Charge (AoC) 

No impact. 

13.10 User-to-User Signalling (UUS) 

No impact. 

13.1 1 Call Barring Services 

13.11.1 Barring of outgoing calls 

No impact. 

13.11.2 Barring of incoming calls 

No impact. 

13.12 Explicit Call Transfer (ECT) 

The procedures specified in 3GPP TS 23.091 [15] for the Explicit Call Transfer supplementary service shall be 
followed. The following clauses describe the additional requirements for the bearer independent CS core network. 

Party A is the subscriber controlling the Exphcit Call Transfer Call (served mobile subscriber). Party B is the first 
remote called party (held party). Party C is the second remote called party. 



13.12.1 Connection of remote parties 

If the result of the ECT checks is successful the MSC server will order the MGW to connect the bearer termination of 
the C-party to the bearer termination of the B-party (bullet 1 in figure 13.24 or in figure 13.21). As a result of this action 
the held party will be retrieved. 

If the call towards the C-party has not been answered, the MSC server requests the MGW to both- way through-coimect 
the bearer temiination towards the C-party. 

13.12.2 I U/A-interface release 

The served party is disconnected after a successful transfer request. The call towards the served mobile subscriber shall 
be released as described in the clause for call clearing. 

13.12.3 Failure handling in MSG server 

If the bearer terminations for the remote parties can not be cormected successfully, the MSC server shall reject the ECT 
request. 
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13.12.4 Example 

Figure 13.23 shows the network model for call explicit call transfer. The "squared" line represents the call control 
signalling. The "dotted" line represents the bearer control signalling and the bearer. Note that for a TDM access case 
there is no separation of call and bearer control signalling. The MSC server moves the bearer terminations of the remote 
parties in the same context and removes the bearer termination for the served mobile subscriber. The bearer termination 
Ta is used for the bearer towards the served mobile subscriber, the bearer termination Tb is used for the bearer towards 
the B-party and the bearer termination Tc is used for the bearer towards the C-party. 




Figure 13.23: ECT (Network model) 
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Figure 13.24 shows the message sequence example for the explicit call transfer when both calls have been answered. In 
the example the MSC server requests the MGW to move the bearer termination for the C-party in the active call to the 
same context which contains the bearer termination for the B-party. The held party is informed about the retrieval of the 
held call. Both the remote parties are informed about the call transfer. After the move the MSC server releases the call 
and the bearer connection towards the served mobile subscriber and requests the MGW to remove the bearer 
termination for the served mobile subscriber. 



UE 
I I 



RNC/BSC 



I I 



MSC-S 



X 



MGW 
□I 



in 



A-B active, held / A-C active, idle 



ECT req 



ECT acknowlec ge 



Context (Cab) 
( 

Context (Cab) 



MOV.request (Tc) 



MOV.reply (Tc) 



Call progress (to 



Call Progress (to 



Call Progress (to 



Call and bearer release 



Context (Cac) 
Context (Cac) 



SUB. request (Ta) 



SUB.reply (Ta) 



Bi 



Bi 



Ci 



Release Termination 



Figure 13.24: Explicit call transfer; both calls answered (message sequence chart) 

Figure 13.25 shows the message sequence example for the explicit call transfer when one call is answered and the other 
call has been delivered. In the example the MSC server requests the MGW to move the bearer termination for the C- 
party in the active call to the same context which contains the bearer termination for the B-party. The held party is 
informed about the retrieval of the held call. Both the remote parties are informed about the call transfer. After the move 
the MSC server releases the call and the bearer connection towards the served mobile subscriber and requests the MGW 
to remove the bearer termination for the served mobile subscriber. The B-party is informed about the active call when 
the C-party sends the Answer indication. 
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UE 
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I I 
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ECT acknowlec ge 



Context (Cab) 
( 

Context (Cab) 



to 



MOV .request (Tc) 



MOV.reply (Tc) 



Call Progress (to 



Call Progress (to 



Call Progress (to 



Call and bearer release 



Context (Cac) 
Context (Cac) 



SUB. request (T^) 



SUB.reply (Ta) 



Answer (from C ) 



Call Progress (to 



Bi 



Ci 



Bi 



Release Termination 



Figure 13.25: Explicit call transfer; other call delivered (message sequence chart) 



13.13 Completion of Calls to Busy Subscriber (CCBS) 

The procedures specified in 3GPP TS 23.093 [16] for the Completion of Calls to Busy Subscriber supplementary 
service and 3GPP TS 23.108 [18] shall be followed. The following clauses describe the additional requirements for the 
bearer independent CS core network. 



13.13.1 Clearing when tones/announcements are provided to the calling 
subscriber 

If an announcement is to be provided for the purpose of notifying the subscriber that CCBS activation is possible, the 
MSC server shall select an MGW. The MGW performs the traffic charmel assignment if the bearer termination has not 
been through-connected (as described in clause 6.1 for the basic mobile originating call). The MGW through-connects 
the bearer before providing the in-band information. The MSC server requests the MGW to play an announcement/tone 
using the Play Announcement or Send Tone procedure. When the announcement has completed the MGW notifies the 
MSC server (using the Announcement Completed procedure as described in clause 14.6) that the announcement is 
complete. 

Otherwise the MSC server handles the call clearing as described in clause 7. 

1 3. 1 3.2 Network initiated mobile originated call 

The call is established as described in clause 6.1 for basic mobile originating caU. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



173 



ETSI TS 123 205 V9.2.0 (2011-04) 



1 3.1 3.2.1 Early Traffic Channel Assignment 

Within CCBS there is an option for a CCBS call to establish a bearer before setup in state "CC-establishment 
confirmed". In this case the MSC server shall check whether an access bearer assignment modification has to be 
performed after receiving the setup message from UE. 

13.13.2.1.1 Example 

For the network model, please refer to figure 6.1. 

Figure 13.26 shows the message sequence chart for the network initiated mobile originating call using the option 
assignment after A and B party alerting. In the following, the case with backward bearer establishment is considered. 



UE 



RNC/BSC 



MSC-S 



Paging + Security 



CCBS] {EC ALL 



SErUl' 



CALL PROC lEDING 



lAB 



ALElTI'sFG 



CONNECT 



Context (CI) 
Context 



(CI) 



Context (C$) 
Context (CI) 
ASSIGNMENT REQ 



MGW 



Initial Addrc ss 



ADD.request ($). 



ADD.reply (T2) 



ADD .request ($) 



_ADD.reply (Tl) 



Bearer Establishment 



ASSIGNMENT COM^L 



Context (CI) 
Context (CI) 



Contini ity 



Address Co mpl ;te 



Answer 



MOD.request (T2) 



_MQD.reply (T2) 



Prepare Bearer 



Bearer Establishment 



Prepare Bearer + Change 
Through-Connection + 
Activate Inter-Working 
function (when applicable) -H 
Activate Voice Processing 
function (when applicable) 



Activate Inter-Working 
function (when applicable) -H 
Activate Voice Processing 
function (when applicable) ^ 



Figure 13.26: Network initiated mobile originating call establishment with assignment 
after A and B party alerting (message sequence chart) 
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13.13.3 CCBS Information conveyed by Call Signalling 

For CCBS, application specific information needs to be conveyed via the call signalling. Specific details of the CCBS 
information are described in 3GPP TS 23.093 [16]. 

13.14 IVIultiple Subscriber Profile (MSP) 

No impact. 

13.15 Multicall 

The procedures specified in 3GPP TS 23.135 [17] for the Multicall supplementary service shall be followed. The 

following clauses describe the additional requirements for the bearer independent CS core network. If out-of-band 
transcoder control is applied for a speech call, it shall be performed in accordance with 3GPP TS 23.153 [3]. 

13.15.1 Mobile Originating 

When the UE is in active mode and it makes a request for the multicall function on a new traffic channel, call and 
bearer estabhshment shall be as described for mobile originating call. 

When the UE is in active mode and it makes a request for the multicall function using an existing traffic channel, call 
and bearer establishment shall be as described for call hold function. An active call wiU be placed on hold and the 
additional originating call will be initiated. 

13.15.2 Mobile Terminating 

When the UE is in active mode and it makes a request for the multicall fiinction on a new traffic channel, call and 
bearer establishment shall be as described for mobile terminating call. Access bearer assignment shall occur either after 
a Call Confirmed or a Connect message is received from the UE. 

When the UE is in active mode and it makes a request for the multicall function using an existing traffic channel, call 
and bearer establishment shall be as described for call hold function. An active call will be placed on hold and the 
additional terminating call will be initiated. 

13.16 Calling Name Presentation (CNAP) 

No impact. 

13.17 Alternate Speech/Fax 

The procedures for facsimile group 3 transparent/non-transparent shall be followed in accordance with 3GPP TS 43.045 
[24] and 3GPP TS 23.146 [25]. The following clauses describe the additional requirements for the bearer independent 
CS core network. If out-of-band transcoder control is applied for a speech call, it shall be performed in accordance with 
3GPPTS 23.153 [3]. 

Call and bearer estabhshment shall be handled as described in the Call Establishment clause. In order to change from 
speech to fax (or vice versa), the MSC server shall modify the access bearer as described in subclause 13.18.1. 

If the MGW responds with an error to any of the procedures initiated by the MSC server, or the MSC server receives a 
Bearer Failure procedure from the MGW, the MSC server may either clear the call or reject the change from speech to 
fax (or vice versa). 

After this possible modification, the MGW shall seize an interworking function if a PLMN Bearer Capability [4] has 
been supphed to the access side bearer termination. When the MSC server receives an answer indication, it shall request 
activation of the interworking fiinction using the Activate Interworking Function procedure. 
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13.18 Modification of the Access Bearer 

13.18.1 IVIodif ication of Bearer Characteristics 

The modification of the access bearer is possible during a call establishment and during an active call. If the MSC 
server needs to modify the access bearer, the existing bearer termination in the MGW is modified or a new access side 
bearer termination is created. The modification of the access bearer shall be performed in accordance with 3GPP TS 
25.413 [26] or 3GPP TS 48.008 [27]. 

13.18.1.1 lu mode 

If the link characteristics for the existing access bearer need to be changed and the MSC server previously received a 
notification from the MGW that modification of Unk characteristics of the current transport coimection is supported 
[refer to 26], the MSC server shall use the Modify Bearer Characteristics procedure to provide the MGW with the new 
bearer characteristics for the existing access side bearer termination. After the MGW has rephed, the MSC server shall 
initiate the access bearer modification towards RAN. 

If the MSC server has not previously received a notification from the MGW that modification of existing link 
characteristics is supported, the MSC server shall use the Prepare Bearer procedure to request the MGW to add a new 
context and a new access side bearer termination, and to provide a bearer address and a binding reference. After the 
MGW has replied, the MSC server shall initiate the access bearer modification towards RAN using the provided bearer 
address and the binding reference. Upon successful access bearer modification, the MSC server shall connect the new 
access side bearer termination to the old context and release the old access side bearer termination. 

If the user plane mode of the modified access bearer is "Support Mode", the lu UP will also be re-initialised as defined 
in [20]. 

13.18.1.2 A/Gbmode 

The MSC server shall use the Modify Bearer Characteristics procedure for A interface TDM termination and may use 
the Modify Bearer Characteristics procedure or the Configure RTP Connection procedure for AoIP termination to the 
MGW to provide the new bearer characteristics for the existing access side bearer termination. After the MGW has 
rephed, the MSC server shall initiate the access bearer modification towards GERAN. 

13.18.2 IWF Protocol Change 

If the MSC server has requested indication on IWF protocol events, the MGW informs the MSC server about changes 
related to IWF protocol, using the Protocol Negotiation Result and Rate Change procedures. 

For AoIP terminations there shall be no change to the AoIP Transport Layer Address (MGW) and AoIP Transport 
Layer Address (ESS) for Rate Changes in data calls. Instead the MSC shall include the previously returned Local 
Connection Address in any subsequent Assignment request to the BSS. 

13.19 GSIVIFax 

The procedures for facsimile group 3 transparent service toward a GSM BSS shall be followed in accordance with 
3GPP TS 43.045 [24]. The following clauses describe the additional requirements for the bearer independent CS core 
network. 

Call and bearer estabhshment shall be handled as described in the Call Estabhshment clause with the addition that the 
Rate Change Event Notification shall be requested. If the MGW detects a mismatch between the radio channel rate to 
the facsimile transmission speed then it shall indicate this to the MSC server by use of the rate change procedure. The 
MSC server shall initiate a new Assignment towards the GSM RAN and if successful modify the PLMN Bearer 
Capability and GSM Channel Coding at the associated access bearer termination using the Modify Bearer 
Characteristics procedure as described in 16.2.41 to signal to the MGW that fax transmission can continue. The 
sequence is shown in Figure 13.19/1. 
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NOT.reply (Tl 



(D 



If channel kept (otherwise assignment message may be sent to MS) 



C lannel Mo|de 
C lannel Molde 



Modify 
Modify ACK 
Assignment Ac 



Context(Cl) 



Context(Cl) 



@ 



MOD.reply 



TlJ) 



MOD.requeft [ vlodify Beai er Characteristics 

(PLMN-BC], 
[GSMchannelCoding] (Tl) 



Figure 13.19/1 : GSM access Channel Mode Modify message 

For AoIP terminations the Configure RTP Connection Point Procedure may be used instead of the Modify Bearer 
Characteristics procedure. 



13.20 Voice group call service (VGCS), Voice broadcast service 
(VBS) 



1 3.20.1 Beginning the Voice group call 



The procedures specified in 3 GPP TS 43.068 [39] for the Voice group call service shall be followed. For a Voice 
broadcast call the procedures in 3GPP TS 43.069 [40] shall be followed. When the served mobile subscriber invokes a 
Voice group call service the MSC server selects an MOW that provides the conference bridge capabiUties with 
enhancements to support Voice group calls. The MSC server shall estimate the size of the Conference terminations 
needed for the VGCS call from the data retrieved from GCR and reserves the requested number of Conference 
terminations for that call. The number of needed corrference terminations is provided within prepare bearer procedure. 

13.20.2 Talker change in Voice group call (1 channel model) 

If the MSC server decides that the talker shall use the uplink associated to the downlink of the ASCI broadcast 
(common group call) channel (Ichannel model, see 3GPP TS 43.068 [39]), the talkers speech is transferred via the 
uplink channel of the ASCI broadcast channel of the cell. The stream arrives within the MGW on the termination of the 
traffic channel serving the cell or BSS (enhanced A-interface) and is transferred to the conference function where the 
summarized conference signal is calculated. The resulting stream is then transferred to all conference terminations. The 
normal behaviour of a conference bridge is to substract for each conference member its own speech (incoming stream) 
from the summarized signal otherwise it hears itself (outgoing stream). Therefore the Talker context need to be 
modified by adding a new termination to the context which is connected to the listener context (see figure 13.20.5/3 and 
13.20.5/5). The topology within the talker context is set oneway from uplink of the ASCI broadcast channel in direction 
to Confernce bridge (old termination of the talker context) and the topology is set to Oneway from the new added 
termination towards the termination connected to the downlink of the ASCI broadcast channel. This is performed using 
establish bearer procedure and change flowdirection. To avoid, that the talker hear himself, the UE internally switch off 
the loudspeaker (muting/unmuting functionality, 3GPP TS 43.068 [39]) on request of the MSC server. 
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13.20.3 Disconnect 

A dispatcher can leave or reenter the call at any time without any influence of the ongoing call. Only the dispatcher is 
disconnected as described in the clause for call clearing (see 3GPP TS 43.068 [39], 3GPP TS 43.069 [40]). 

The Voice group call can only be released by an authorised subscriber (see 3GPP TS 43.068 [39], 3GPP TS 43.069 
[40]). If an authorised subscriber triggers the release of the group call all other parties are disconnected as described in 
the clause for call clearing. 

13.20.4 Failure InancJIing in MSG server 

If resources for the Voice group call service cannot be allocated in any of the MGW resources assigned to the MSG 
server (e.g. not enough conference terminations are available with cause "510 - Insufficient resources"), then the MSG 
server shall reject the VGCS request. 

13.20.5 Example 

Figure 13.20.5/1 shows a possible network model of an anchor MSG for a voice group call when the Talker is on the 
dedicated channel. At call setup Dispatchers, R-MSG and the talker can been seen as a multi party call. The listners are 
connected oneway in their context (bullet 1 and 2 in figure 13.20.5/2). In the example every kind of termination is 
shown in its own context. 



Dispatcher 



R-MSC 



BSS 



BSS 



BSS 




Figure 13.20.5/1 : VGCS call (termination overview for talker on dedicated channel) 

If the talker is on a dedicated channel, the talker context contains two terminations which are connected bothway a 
termination overview is given in figure 13.20.5/1. 
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Figure 13.20.5/2 shows the message flow establishment of a VGCS call with two cells and the talker is located in celll 
when the Talker is on the dedicated channel. To connect the parties to the VGCS Multi Party Bridge the MSG server 
requests the MGW to establish internal Nb connections between the bearer terminations in the VGCS Multi Party 
bridge context and the call leg contexts, using the standard external bearer setup procedures. VGCS call acknowledge 
(bullet 3 in figure 13. 20. 5/2) should be send after the ASCI broadcast channel is estabUshed in the cell where the talker 
is located (see 3GPP TS 43.068 [39], 3GPP TS 43.069 [40]). 
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Figure 13.20.5/2: Talker on dedicated cliannel (lUlessage sequence cliart) 

Figure 13.20.5/3 shows a possible network model of an anchor MSG for a voice group call when the Talker is on one 
channel mode. 
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Figure 13.20.5/3: VGCS call (termination overview for Talker on one channel model) 

Figure 13.20.5/4 shows the message flow establishment of a VGCS call with two cells and the talker is located in celll 
when the Talker is on one channel mode. 
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Figure 13.20.5/4: Taiker on one channei mode (lUlessage sequence cliart) 
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Figure 13.20.5/5 shows the message flow of the talker move to uplink. 

If the MSC server decides that the talker shall use the uplink of the cell. The MSC server adds a termination to the 
talker context which is connected to the Listener context and changes the topology of the talker context (bullet 1 and 2 
in figure 13.20.5/5). Substract of the termination of the talker is only performed when the MSC server decides to move 
an active talker to the ASCI broadcast channel (bullet 3 in figure 13.20.5/5). The termination towards the cell where the 
talker is located is moved to the talker context. Further talker changes or cell changes of the current talker would be 
handled with move commands related to the termination towards the cell where the talker is located (bullet 4 in figure 
13.20.5/5). Thus the talker's speech to all the listeners in that cell is transmitted (broadcast channel). The termination 
overview after the talker is moved to the uplink is given in figure 13.20.5/3. 
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Figure 13.20.5/5: Information flow talker move to uplink (Message sequence chart) 



14 Interactions with Other Network Features and 
Services 

NOTE: All message sequence charts in this clause are informative examples. 

14.1 Customised Applications for IVIobile network Enhanced 
Logic (CAIVIEL) 

If the gsmSRF is co-located with the (G)MSC server, the gsmSRF is divided into a gsmSRF server and an MGW. The 
gsmSRF server terminates the CAP protocol and signals over the Mc interface to instruct its MGW to provide the 
required resource. All the logic of the gsmSRF is located in the gsmSRF server. The MGW provides only simple 
resources for playing a single announcement or tone, or detection of single DTMF tone pair. If one single resource in 
the MGW does not fulfil the requirement of the gsmSCF, the gsmSRF server has to use different resources in sequence 
to fulfil the whole requirement. 
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The gsmSSF uses the capabilities of the (G)MSC server and the MGW to play announcements or send tones to the 
server. 

NOTE 1: In the subsequent figures within clause 14.1, the "Connect To Resource" scenario is used. However the 
other CAMEL Intelligent Peripheral (IP) scenarios are not intended to be excluded. No impacts are 
identified when applying these other CAMEL scenarios. 

NOTE 2: The gsmSRF functionahty may be deployed within the MSC server, and either the current serving MGW 
or any MGW resource under the control of the current MSC server. 

14.1.1 Play Announcement/Send Tone 

The playing of an announcement or sending of a tone shall be performed in accordance with 3GPP TS 23.078 [10]. It is 
assumed that the MGW selected for the call has the capabilities to provide announcements and tones. 

When the gsmSCF requests the gsmSRF to play a specified announcement or tone, the gsmSRF orders the MGW to 
play the announcement or tone as described in clause 14.6. 

After the gsmSRF has received the announcement or tone completed notification from its MGW, it reports the 
announcement or tone completion to the gsmSCF. 

If the gsmSCF requests the gsmSRF to cancel the earlier started announcement or tone, the gsmSRF orders the MGW to 
stop playing the announcement or tone as described in clause 14.6. 

14.1 .1 .1 Example of playing announcement by the gsmSRF 



gsmSCF 



(G)MSC-S/gsmSRF 



Connect To Resource 



Play Announcement^ 



Spscialized Resource Repcrt 



MGW/gsmSRF 



Play 
announcement 



Figure 14.1 : CAMEL Announcement Playing (message sequence chart) 

14.1.2 User Interaction 

The user interaction shall be performed in accordance with 3GPP TS 23.078 [10]. It shall be assumed that the MGW 
selected for the call has the capabilities to provide announcements. In bearer independent CS core network the DTMF 
digits can be propagated inband or out-of-band. 



14.1.2.1 Play announcement 

When the gsmSCF requests the gsmSRF/SSF to play a specified announcement and to collect digits that are sent by the 
user the gsmSRF/SSF requests the MGW to play the announcement as described in clause 14.6. 
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14.1.2.2 



Detect DTMF tones 



The gsmSRF/gsmSSF starts detecting DTMF tones, as describes in clause 14.4.2, before it receives the announcement 
or tone completed notification (see clause 14.6). 

14.1.2.3 Report DTMF tones 

The DTMF tones are reported to the gsmSRF/SSF as described in clause 14.4.2. After all requested digits are received 
the gsmSRF/SSF reports the digits to the gsmSCF. 

14.1 .2.4 Cancel prompt and collect user information 

If the gsmSCF requests the gsmSRF to cancel the prompt and collect user information procedure, which had been 
started earlier, the gsmSRF orders the MGW to stop playing the announcement or sending tone, if they are still in 
progress , using the Stop Announcement or the Stop Tone procedure. The gsmSRF shall also order the MGW to stop 
detecting DTMF tones using the Stop DTMF Detection procedure. 



gsmSCF 



Pi om It And Collect User Ii^ o rma don 



gsmSRF/SSF 



Connect To Resourc^ 



Prom pt / ^ Collect User Inform s tior Ack 



MGW 



Inband DTMF 
detection and 

Play 
announcement 



Out-of-band DTMF detection 



Figure 14.2: CAMEL User Interaction (message sequence chart) 



NOTE: Since gsmSRF don not know whether DTMF digits are provided inband or out-of-band the gsmSRF has 
to be able to collect DTMF tones both inband and out-of-band. 



14.1.3 Call Party Handling (CPH) 

The procedures specified in 3GPP TS 23.078 [10] for Call Party Handling (CPH) shall be followed. The following 
clauses describe the additional requirements for the bearer independent CS core network. 

In contrast with HOLD and MPTY, the call parties created on instruction from the gsmSCF are not seen as separate 
calls in the Mobile Station, i.e. all call parties in a CPH configuration use the same transaction id towards the MS. In 
addition, CPH may take place in an MSC-S different from the one where the CAMEL served subscriber is registered. 
Furthermore, in CPH it is possible to have multiple call parties in separate call segments whereas the call hold 
supplementary service has a limit of one held call party and one active call. 

The gsmSCF always triggers the elementary procedures which are described in this subclause. CPH elementary 
procedures can be used in more complex procedures to provide useful services, but the more complex procedures are 
out of scope of this specification. 

NOTE: For simplicity, the figures below which show network models do not show the gsmSCF. The gsmSCF is 
in the HPLMN of the served (CAMEL) party. The GMSC-S is in the interrogating network (IPLMN). 
The MSC-S is in the VPLMN of the served party. 
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Use of a multi-party (conference) bridge 

When the gsmSCF invokes a CPH procedure which requires the connection of three or more legs in a muhi-party 
configuration, the MSC server selects an MGW which provides multi-party bridge capabilities. The timing of the 
selection of the MGW with the multi-party bridge capabilities is vendor specific. If the selected MGW is not the MGW 
which is used for the active call, the MSC server requests the MGW(s) to connect the bearer terminations of the 
participants to the selected MGW. The bearer terminations are connected together. 

14.1 .3.1 Call Party Handling concepts 

The relationship between Call Segments and voice connections is explained in 3GPP TS 23.078 [10] subclause 4.5.1. 

14.1 .3.2 Initiate Call Attempt procedure 

The Initiate Call Attempt (ICA) procedure is used either: 

• To create a new call (out-of-the-blue), in which case the gsmSCF makes the initial contact with the MSC-S, or 

• To create an additional call party in an existing call. The new call party is always created in a new call 
segment. The existing call may have triggered contact with the gsmSCF based on CAMEL subscription 
information (MO or MT in VMSC, MT in GMSC, call forwarding etc), or the gsmSCF may have initiated the 
contact using the ICA procedure (out-of-the-blue). 

The gsmSCF may create additional call parties before it establishes the bearer to the calling party. The 
MSC-S/GMSC-S shall establish bearers to the additional call parties independently of the other parties, including the 
calling party. 

The leg which is created by the Initiate Call Attempt procedure is initially in the held state. 

14.1.3.2.1 Example 

Figure 14.1.3/1 shows an example network model for the Initiate Call Attempt procedure with an establishment of a 
new call leg. The "squared" line represents the call control signalling. The "dotted" line represents the bearer control 
signalling and the bearer. The MSC-S seizes a new context with one bearer termination in the MGW which is used for 
the new call leg. 



A-B 2-party call before ICA: j^A for new call to C subscriber: 




Figure 14.1.3/1 Initiate Call Attempt procedure (Network model) 

Figure 14. 1.3/2 shows an example message sequence for the Initiate Call Attempt procedure. 
In this example a new call leg to the C-party is established. 
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gsmSCF 



(G)MSC-S 



Initiate Call Attempt 



Context($) 
Context(Cc) 
Initiate Call Attempt Adk 



MOW 



ADD.request($) 



ADD.reply(Tc) 



CAP operations 



Continue With Argumei it 



Call and Bearer 
Establishment => C-party 



Figure 14. 1.3/2 Information flow for Initiate Call Attempt (message sequence chart) 
14.1 .3.3 Move Leg procedure 

The Move Leg procedure is used to move a leg from its current call segment to the (existing) target call segment. 

Using Move Leg to add a leg to a call segment which already includes 2 call legs requires the establishment of a 
multiparty call (if it does not akeady exist for the served CAMEL subscriber) as described in clause 13.7. Other call 
parties may be involved in independent Multiparty calls due to MPTY SS or CPH. If the call segment to which the 
specified leg is added is akeady using a multi-party bridge, the MSC server requests the MGW to establish the 
connection between the specified leg and the multi-party bridge. 



Example 

Figure 14. 1.3/3 shows an example network model for the Move Leg procedure. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer control signalling and the bearer 
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Situation before MoveLeg 



Situation after MoveLeg 




C party 




C party 



Figure 14. 1.3/3 Move Leg procedure (Network model) 

Figure 14. 1.3/4 shows an example message sequence for the Move Leg procedure. 

In this example the leg of the C-party is moved to an existing call segment. The MSC-S requests the MGW to move the 
bearer termination for the C-party to the same Context which contains the bearer termination for the A-party 



gsmSCF 



(G)MSC-S 



MoveLeg 



© 



Context (Cab) 
Context (Cab) 



Return Result 



MGW 



MOVE.request(Tc) 



MOVE.reply(Tc) 



Move Tr to Ca 



Figure 14. 1.3/4 Information flow for Move Leg (message sequence chart) 



14.1 .3.4 Split Leg procedure 

The Split Leg procedure is used to separate a call leg from a source call segment and place it in a (new) target call 
segment. 

When the gsmSCF uses the Split Leg procedure to put a call leg on hold, the MSC server instructs the MGW to 
interrupt the connection between the specified call leg and the other party/parties in the call segment. If the call segment 
is using a multi-party bridge, the connection from the specified call leg to the multi-party bridge is interrupted. 
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Example 

Figure 14. 1.3/5 shows an example network model for Split Leg procedure. The "squared" line represents the call 
control signalling. The "dotted" line represents the bearer control signalling and the bearer. 



Situation before SplitLeg 



Situation after SplitLeg 




B party 




^{NC/BSCr ^ CTXab 



MGW 




CTXb 



X B party 



Figure 14. 1.3/5 Split Leg procedure (Network model) 

Figure 14. 1.3/6 shows an example message sequence for the Split Leg procedure. 

In this example the leg of the B-party is moved to a new call segment. The MSC-S requests the MGW to move the 
bearer termination for the B-party in the active call to a new context. 



gsmSCF 



(G)MSC-S 



SplitLeg 



Context (C$) 
Context (Cb) 



Return Result 



MGW 



MOVE.request(TB) 



MOVE.reply(TB) 



Move Tb to Cb 



Figure 14. 1.3/6 Information flow for Split Leg (message sequence chart) 



14.1 .3.5 CAMEL User interaction procedure 

In accordance with 3GPP TS 23.078 [10] the gsmSCF may order the MSC-S/gsmSSF to play an announcement or 
control user interaction as specified in subclauses 14.1.1 and 14.1.2 respectively. The tones are provided in accordance 
with subclause 14.6 of the present document. As part of Call Party Handling, announcements or tones can be played to 
an individual party or to all the parties connected in the call segment. 
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The gsmSCF may also instruct the MSC-S to establish a temporary coimection to an external device which provides the 
user interaction. 

14.1 .3.6 Failure handling in the MSC-S 

If resources for Call Party HandUng cannot be allocated in any of the MGWs assigned to the MSC-S, then the MSC-S 
shall reject the request for the Call Party HandUng procedure. 

14.2 1ST 

The handling of 1ST shall be performed in accordance with 3GPP TS 42.032 [19]. This clause describes the additional 
requirements for the Bearer Independent CS Core Network. 

The clearing of calls due to 1ST is the same as for (G)MSC server initiated call clearing, refer to clause 7.3,(G)MSC 
server Initiated. 

14.3 Operator Determined Barring (ODB) 

NOTE: The subsequent clauses in 14.3 describe the impacts of "Barring of Outgoing Calls" and "Barring of 

Incoming Calls" on Bearer Independent CS CN. Other flavours of Operator Determined Barring may be 
supported by the Bearer Independent CS CN. However no impacts caused by these other flavours are 
identified. 

14.3.1 Barring of Outgoing Calls 

If the mobile station attempts to coimect to an address determined to be barred by the Operator Determined Barring 
service, the call shall be cleared as described in clause 7, Call Clearing. 

Otherwise, the call is estabUshed as described in clause 6, Call Establishment. 

14.3.2 Barring of Incoming Calls 

If the incoming call to the mobile station is determined to be barred by the Operator Determined Barring service, the 
call shall be barred. Otherwise the call shall be deUvered as described in clause 6, Call Estabhshment. 

If the GMSC connects the call to a recorded announcement due to Operator Determined Barring, the GMSC server 
selects the MGW before providing the in-band information. It is possible that the MGW selection is based on an MGW- 
Id received from the preceding node. 

The incoming side bearer establishment is handled in the GMSC server as described for the mobile terminating call 
using either forward or backward bearer establishment. 

In-band information may be provided to the calling subscriber only when both of the following conditions are satisfied: 

1. Either: 

a. The incoming lAM indicated that the Continuity message will follow, and a Continuity message has been 
received, or 

b. The incoming lAM did not indicate that the Continuity message will follow; 

2. Notification indicating successful completion of the incoming side bearer set-up has been received from the 
MGW using the Bearer Established procedure. 

The GMSC server provides the MGW with the announcement identification and requests the MGW to notify the 
announcement completion using the Play Announcement procedure as described in clause 4.6. 

After the possible announcement has been completed the GMSC server initiates the call release as described in the 
clause 7, Call Clearing. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



189 



ETSI TS 123 205 V9.2.0 (2011-04) 



14.4 



DTMF 



DTMF information can be transported either inband or out of band. In order to minimise the interworking between out 
of band and in band DTMF signalling, the general principle is to use the DTMF signalling method of the preceding 
node whenever possible. A node supporting OoB DTMF shall also be able to receive inband DTMF digits, but no 
DTMF digits shall be dupUcated, i.e. any detected digit shall either be sent forward by inband or out-of-band, but never 
by both methods. Transitions between inband and out-of-band may occur due to changes to an ongoing call (ExpUcit 
Call Transfer for example) but digits shall not be sent both inband and OoB for the same link. 

If out-of-band transcoder control is applied for a speech call, it shall be performed in accordance with 
3GPPTS 23.153 L3J 

14.4.1 DTMF Tone Generation 
14.4.1.1 Inband DTMF Tone Generation 

This option uses inband signalUng to transport DTMF digits in the core network. 

The DTMF tone generation shall be performed in accordance with 3GPP TS 23.108 [18]. The following clauses 
describe the additional requirements for the bearer independent CS core network. 

14.4.1.1.1 Start DTMF 

When the MSC server receives the Start DTMF message from the UE, it uses the Send DTMF procedure to request the 
MGW to modify the bearer termination to play a tone for the pressed digit. The result of the tone sending by the bearer 
termination will be received by the MSC server and sent to the UE (bullet 1 in figure 14.3). 



When the MSC server receives the Stop DTMF message from the UE, it uses the Stop DTMF procedure to request the 
MGW to modify the bearer termination to stop digit playing. When the response is received from the MGW, the MSC 
server will acknowledge the Stop DTMF (bullet 2 in figure 14.3). 



The MGW shall check the minimum duration and minimum interval in accordance with the DTMF timing defined in 
TS 23.014 [33]. 



Figure 14.3 shows an example where out-of-band signalling of DTMF information is not supported by the call control 
protocol. When the UE sends Start DTMF and Stop DTMF messages , the MSC server uses resources in the MGW to 
generate tones by modifying the bearer termination. 



14.4.1.1.2 



Stop DTMF 



14.4.1.1.3 



Example 
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UE 



RNC 



START D TMF 



START DT]\ IF ACK 



STOI'DTMF 



STOPKTIVFACK 



MSC-S 



Context (Cx) 
Context (Cx) 



Context (Cx 
Context (Cx) 



MOW 



MOD.request (Tx) 



MOD.reply (Tx) 



MOD.request) 



MOD.reply (Tx) 



Send DTMF 



Stop DTMF 



Figure 14.3: Inband DTMF generation (message sequence cliart) 



14.4.1.2 



Out-of-Band DTMF Tone Generation 



This option uses out-of-band network signalling to transport DTMF digits in the core network, where the information is 
sent on a call control layer. 

The DTMF Tone Generation shall be performed in accordance with 3GPP TS 23.108 [18]. The following clauses 
describe the additional requirements for the bearer independent CS core network. 



14.4.1.2.1 



Start DTMF 



When the MSC server receives a Start DTMF message from the UE, it indicates digit playing using out-of-band 
signalhng. The corresponding result received from the preceding/succeeding node will be sent to the UE (bullet 1 in 
figure 14.4). 



14.4.1.2.2 



Stop DTMF 



When the MSC server receives a Stop DTMF message from the UE, it indicates stop digit playing using out-of-band 
signalling. The succeeding node will indicate that digit playing is stopped. The MSC server will send the result back to 
the UE (bullet 2 in figure 14.4). 



14.4.1.2.3 



Example 



Figure 14.4 shows the message sequence example for the out-of-band DTMF during a call. When the MSC server 
receives the Start DTMF and Stop DTMF messages from the UE, it shall send the iirformation using signalling on call 
control layer. The MSC server wiU not use any dedicated resources of the MGW. 
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UE 



RNC 



START D TMF 



START DTMFACK 



STOI'DTMF 



STOPKTIVFACK 



MSC-S 



Ext 



Start DTMF 



Start DTMF Ack 



Stop DTMF 



Stop DTMF Ack 



Figure 14.4: Out-of-Band DTMF generation (message sequence cliart) 



14.4.2 DTMF Detection 



14.4.2.1 



Inband DTMF Detection 



The (G)MSC server/gsmSSF/gsmSRF requests the MGW to detect DTMF tones using Detect DTMF procedure 
(bullet 1 in figure 14.5). 

At detection of the DTMF tone the MGW reports the digit to the (G)MSC server/gsmSSF/gsmSRF using the Report 
DTMF procedure (bullet 2 in figure 14.5). At reception of the DTMF tone report the (G)MSC server/gsmSSF/gsmSRF 
either expects the MGW to detect other DTMF tones (in which case no new Detect DTMF request needs to be sent) or 
requests the MGW to stop the detection of DTMF tone (buUet 3 in figure 14.5) using the Stop DTMF Detection 
procedure. 



(G)MSC-S 



Context (Cx; 
Context (Cx) 

Context (Cx)| 
Context (Cx) 



Context (Cx 
Context (Cx 



MGW 



MOD.request (Tx)__ 



MOD.reply (Tx) 



NOTIFY.request (Tx) 



NOTIFY.reply (Tx) 



MOD.request (Tx ^ 



MOD.reply (Tx) 



Detect DTMF 

Digit 1, 2 or 3 Played 
Report DTMF 

Stop DTMF Detection 



Figure 14.5: Inband DTiUlF detection (message sequence chart) 
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14.4.2.2 



Out-of-Band DTMF Detection 



The (G)MSC server/gsmSSF/gsmSRF starts collecting out-of-band DTMF tones. One DTMF tone consists of Start 
DTMF (bullet 1 in figure 14.6) and Stop DTMF messages (bullet 2 in figure 14.6). 



(G)MSC-S 



(S 



MGW 



^ Start DTMF 






Start DTMF A( 


;k 




^ Stop DTMF 






Stop DTMF Ac 


k 











Figure 14.6: Out-of-Band DTMF detection 
(message sequence chart) 



14.5 OR 

The procedures specified in 3GPP TS 23.079 [11] for the Optimal Routeing network service shall be followed. The 
following clauses describe the additional requirements for the bearer independent CS core network. 

14.5.1 Optimal routeing for basic mobile-to-mobile calls 

The optimally routed call from one mobile subscriber to another mobile subscriber is established as a normal basic call. 

14.5.2 Optimal routeing for conditional call fonwarding; Early call fonwarding 

For early call forwarding the same procedures as described for CFU and CFNRc (rerouting by HLR) shall apply. 

14.5.3 Optimal routeing for conditional call fonwarding; Late call forwarding 
14.5.3.1 MSG server 

1 4.5.3.1 .1 Resume Call Handling and clearing of connection to GMSC server 

When the MSG server determines that the call should be forwarded because the called mobile subscriber is busy 
(NDUB, UDUB), not reachable or has not replied to the call before the no-reply timer has expired, the MSG server 
sends a request to resume call handling to the GMSG server. 

If the GMSC server determines that the call can be forwarded to the forwarded-to destination it sends a Release 
message to the MSG server. If no bearer has been established yet the MSG server handles the release only on call 
control level. If the bearer had been established, the MSG server handles the network side bearer release as described in 
the clause for the call clearing. 



14.5.3.1.2 



lU release 



When the MSG server determines that the call should be forwarded because the called mobile subscriber is busy 
(UDUB) or it has not replied to the call before the no-reply call timer has expired, the MSG server shall release the call 
and bearer connection to the served mobile subscriber as described in the clause for call clearing. 
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14.5.3.2 G MSG server 

14.5.3.2.1 Resume Call Handling and Clearing of Connection to visited MSC server 

If the GMSC server determines that the call can be forwarded to the forwarded-to destination it sends a Release 
message to the MSC server and handles the outgoing side bearer release as described in the clause for call clearing, if 
the bearer had already been established. 

14.5.3.2.2 MGW selection 

The GMSC server shall select an MGW for the bearer connection as described for the CFU and CFNRc (in HLR) 
supplementary services, if not already selected by the mobile terminating call procedures. 

14.5.3.2.3 Incoming side bearer establishment 

The bearer establishment towards the preceding MGW is handled in the GMSC server as described for the mobile 
terminating call, if not already established by the mobile terminating call procedures. 

14.5.3.2.4 Notification to the Calling Subscriber 

The GMSC server sends the possible notification towards the calhng subscriber according to the procedures described 
for the CFU and CFNRc (in HLR) supplementary services. 

1 4.5.3.2.5 Establishment of call and bearer towards the forwarded-to subscriber 

The GMSC server establishes the call and bearer towards the forwarded-to subscriber according to the procedures 
described for the CFU and CFNRc (in HLR) supplementary services. 

14.5.3.2.6 Example 

Figure 14.7 shows the network model for optimal routeing when no bearer has been established before the invocation of 
late call forwarding. The "squared" line represents the call control signalling. The "dotted" line represents the bearer 
control signalling and the bearer. The GMSC server seizes one context with two bearer terminations in the MGW. The 
bearer termination Ta is used for the bearer towards the preceding MGW (calling subscriber) and the bearer termination 
Tc is used for the bearer towards the succeeding MGW (forwarded-to subscriber). 

Before CFB (NDUB), CFNRc: After CFB (NDUB), CFNRc: 




Figure 14.7: Optimal routeing; late call forwarding (CFB (NDUB), CFNRc) (Network model) 

Figure 14.8 shows the message sequence example for the optimal routeing with late call forwarding without any 
notification to the calling party. In the example below no bearer has been established for the connection when the MSC 
server sends the Resume Call Handling request to the GMSC server. After the call towards the visited MSC server has 
been released the GMSC server establishes the call and the bearer as described for Call Forwarding Unconditional. 
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GMSC-S 



Initial Access 



MGWgmsc 



Initial Addres: ; 



MSC-S 



MGWmsc 



CFB (NDUB), 
CFNRc 



Resume Call Handling 



Release 






J^elease Com 


Diet 











Normal call and bearer establishment to forwarded-to subscriber 



NOTE: CFB Call Forwarding on Busy 

NDUB Network Determined User Busy 
CFNRc Call Forwarding on Not Reachable 

Figure 14.8: Information flow for optimal routeing; late call forwarding (CFB (NDUB), CFNRc) 

(message sequence chart) 

Figure 14.9 shows the network model for optimal routeing when a bearer has been established before the invocation of 
late call forwarding. The "squared" line represents the call control signalling. The "dotted" line represents the bearer 
control signalling and the bearer. The GMSC server replaces the bearer termination towards the visited MSC server 
(Tmsc) with the bearer termination for the forwarded-to subscriber (Tc) in an existing context in the MGW. The bearer 
termination Ta is used for the bearer towards the preceding MGW (calling subscriber). 



Before CFB (UDUB), CFNRy, CD: 



After CFB (UDUB), CFNRy, CD: 





^ CTXl ^ ^ CTXab ^ RNC 




Figure 14.9: Optimal routeing; late call forwarding (CFB (UDUB), CFNRy, CD) (Network model) 
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Figure 14.10 shows the message sequence example for the optimal routeing for late call forwarding with a forward 
bearer release. In the example the MSC server requests the MGW to remove the termination towards the served mobile 
subscriber after the bearer towards the RNC has been released. At reception of the release message from the GMSC 
server the MSC server requests the MGW to be prepared for the bearer release. When the GMSC server receives the 
Release Complete it requests the MGW to release the bearer. 



GMSC-S 



(C) 



Context 
Context (C 
Context 
Context 



(CI) 



(CI) 



MGWgmsc 



MSC-S 



MGWmsc 



RNC 



UE 



Mobile terminating call and bearer establishment 



CFBCUDUB), 
No reply, CD 



Context (Cab) 
Context (Cab) 



Resume Call Handling 



Release 



Release Complete 



MOD .request (T, 



MOD.reply ( Fj 



SUB.requesi (T^sc) 



SUB.reply ('^, 



Context (Cab) 
Context (Cab) 



use) 

)Release Bearei 



)Release Termination 



Call and bearer release 



SUB. request 



SUB.reply (T 



SUB. request 



SUB.reply (T 



Bearer release 



Tb) 

b) 



Ta) 
) 



Release Termination 



Release Termii iati( m 



Call and bearer establishment to forwarded-to subscriber 



NOTE: CFB Call Forwarding on Busy 

UDUB User Determined User Busy 
CD Call Deflection 



Figure 14.10: Information flow for optimal call routeing; late call forwarding (CFB (UDUB), 
CFNRy, CD), forward bearer release (message sequence chart) 
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Figure 14.1 1 shows the message sequence example for the optimal routeing for late call forwarding with a backward 
bearer release. In the example the MSC server requests the MGW to remove the termination towards the served mobile 
subscriber after the bearer towards the RNC has been released. At reception of the release message from the GMSC 
server the MSC server requests the MGW to be release the bearer. When the GMSC server receives the Release 
Complete it requests the MGW to remove the bearer termination. 
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Figure 14.11: Optimal call routeing; late call forwarding (CFB (UDUB), CFNRy, CD), 
backward bearer release (message sequence chart) 
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14.6 Providing tones or announcements. 

It shall be assumed that the MGW selected for the call has the capabiUties to provide announcements and tones. 

14.6.1 Preconditions when providing in-band information to the calling 
subscriber 

For a mobile terminating/forwarded call, announcements/tones may be provided to the calUng subscriber only when 
both of the following conditions are satisfied: 

1. Either: 

a. The incoming lAM indicated that the Continuity message wiU foUow, and a Continuity message 
has been received, or 

b. The incoming lAM did not indicate that the Continuity message will follow; 

2. Notification indicating successful completion of the incoming side bearer set-up has been received from 
the MGW using the Bearer Established procedure. 

For a mobile originating call, the traffic channel assigimient shall be completed before providing the in-band 
information to the calUng subscriber. 

14.6.2 Preconditions when providing in-band information to the called 
subscriber 

The called party is selected by the calling party, or a supplementary service (call forwarding, call deflection, CAMEL 
redirection etc), or a call is initiated by the gsmSCF using the Initiate Call Attempt procedure. The called party may also 
be in the PSTN. 

Announcements/tones may be provided to the called subscriber only when both of the following conditions are 
satisfied: 

1 . The called party has answered and is still active in the call. 

2. Notification indicating successful completion of the outgoing side bearer set-up has been received from the 
MGW using the Bearer Established procedure. 

14.6.3 Preconditions when providing in-band information to multiple 
subscribers 

The gsmSCF may instruct the MSC-S/gsmSSF to provide announcements or tones for multiple subscribers. For each 
calling and called subscriber the precondition for calling and called subscriber (respectively) shall be fulfilled. If the 
preconditions are not fulfilled for all subscribers (e.g. one of the called parties is in the alerting phase), then the 
announcements/tones shall not be played to the subscribers who do not meet the preconditions, but the 
announcements/tones shall be played to the subscribers (if any) who meet the preconditions. 

1 4.6.4 Request to play an announcement/tone 

The (G)MSC server/gsmSSF/gsmSRF provides the MGW with the announcement/tone identification and optionally 
requests the MGW to notify the announcement/tone completion using the Play Announcement or Send Tone procedure 
(bullet 1 in figure 14.13). 

14.6.5 Stopping an announcement/tone 

The (G)MSC server/gsmSSF/gsmSRF can order the MGW to stop the current announcement/tone using the Stop 
Aimouncement or Stop Tone procedure (buUet 2 in figure 14.13). 
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14.6.6 Announcement/tone completed 

If notification of the announcement/tone completion was requested in the Play Announcement or Send Tone procedure, 
the MGW notifies the (G)MSC server/gsmSSF/gsmSRF when the announcement/tone has been completed using the 
Announcement Completed or Tone Completed procedure (bullet 3 in figure 14.13). 

14.6.7 Example 1 

Figure 14.12 shows the network model for providing in-band information to the calling subscriber where the (G)MSC-S 
requests to play the announcement/tone directly on the desired termination from which the signal shall be sent. The 
"squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling and the 
bearer. The bearer termination Tx is used for the bearer towards the preceding MGW (calling subscriber). 

A bearer termination Ty may exist in the same context towards the succeeding MGW (called subscriber) and may be 
both-way connected and through-connected with Tx. In that case, the exchange of media streams between the 
terminations Tx and Ty is assumed to be normally interrupted during playing the announcement in the direction towards 
which the announcement is played. 




Alternative 1 Alternative 2 

with only Tx in the context with Tx and Ty in the context 



Figure 14.12: Providing in-band information 
(Network model) 

Figure 14.13 shows the message sequence example for providing the calling party with an announcement/tone. In the 
example the (G)MSC server requests the MGW to play an announcement/tone and to notify the announcement/tone 
completion. The (G)MSC server may stop the announcement while the current announcement/tone is ongoing. 
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Figure 14.13: Playing an announcement/tone (message sequence chart) 



14.6.8 Example 2 

Figure 14.6.8/1 shows the network model for providing in-band information to the calling subscriber where the 
(G)MSC-S requests to play the announcement/tone on another termination in the context connected via topology 
information to the desired termination(s). E.g. during the call setup, the MSC-S requests the MGW to send a ring back 
tone to the calling subscriber when receiving the indication that the called subscriber is being alerted. 

The "squared" line represents the call control signalling. The "dotted" line represents the bearer control signalling and 
the bearer. The in-band information applied on the TO termination is forwarded to the bearer termination(s) towards 
which the topology association is either 'oneway' or 'bothway', i.e. towards the Ta termination in this example. 




Figure 14.6.8/1: Proving in-band information 
(Network model) 

Figure 14.6.8/2 shows the message sequence example for providing the calling party with the announcement/tone. In 
the example the MSG requests the MGW to play an announcement/tone by seizing a new ephemeral 
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announcement/tone termination with the indication that a tone or announcement shall be forwarded internally to the 
bearer termination(s) towards which the topology association is either 'oneway' or 'bothway'. 
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OR2: Stop the announcement/tone (Y: yes , N::no) 

Figure 14.6.8/2: Playing an announcement/tone (message sequence chart) 



1 4.7 Global Text Telephony 



3GPP TS 23.226 [26] describes the high level architecture and functionality of GTT. When text based conversation is 
needed by a subscriber, the call is established with general call control functions like any other call. Within the call 
control transactions the UE indicates the need for text conversation (see 3GPP TS 24.008 [4]), which then requires 
actions in the core network where the pooling mechanism is chosen for GTT feature. This section describes only the 
option where the CTM pool is provided in the Media Gateway in the Core Network. 

MSG Server receives an indication by the UE about the need of text conversation, allocates terminations in MGW with 
CTM (Cellular Text telephony Modem) capabilities for the detection of CTM signals from radio access network. The 
default action of the call path in the CTM-detection/conversion function in MGW is to transfer audio transparently 
while monitoring for text telephone signals. When valid text telephone signals are detected, the converting action of the 
channel takes effect. The path converts between the detected CTM at the access termination and PSTN text telephony 
signalling methods on the network side. This mode of operation continues until text signalling ceases. Then transparent 
audio transport is re-estabUshed, again monitoring for text signals. 

The CTM channel is created with Prepare bearer for lu/ATM terminations. Prepare IP Transport for lu/IP 
terimnations,Reserve circuit procedure for A interface over TDM terminations or with Reserve RTP Connection Point 
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for A interface over IP by including Cellular Text Telephone package properties. The core network bearer shall be 
established with default PCM codec to carry the T.140 protocol. 

The outcome of CTM negotiation towards the CTM user in the user plane is reported in the CTM report procedure. 

At release the MGW may report the number of bits of Global Text Telephony data in accordance with ITU 
recommendation T.140 sent for the call. 

14.8 Emergency Calls 

Emergency Calls shall be handled as in clause 6.1 Basic Mobile Originating Call, and clause 6.2 Basic Mobile 
Terminating Call. The Procedure Emergency Call Indication may be used for informing the MGW about the emergency 
call. 

1 4.9 Subscriber and equipment trace 

For the subscriber and equipment trace the MSC server may be activated for tracing (see 3GPP 32.421 [34]). Besides 
performing trace record generation, if Signalling based activation the MSC server shall forward the Trace Session 
activation to GERAN with BSSAP signaling, UTRAN with RANAP signaling (see 3GPP TS 25.413) and if the trace 
control and configuration parameters are defined so, the MGW. For detailed description of trace session activation 
mechanism see 3GPP TS 32.422 [35]. The activation to the MGW is sent using a trace package which is included either 
to the Add or Modify command(s) in mobile originated call or mobile terminating call. In the case of handovers where 
new termination is created the trace package is also included into the Add command. If the MSC does not receive the 
optional trace interface list IE in the trace activation request it shall request tracing on all terminations that support the 
total MGW trace interfaces as defined in TS 32.422. The MSC Server shall only set the trace interface Ust value that is 
associated to the interface that the termination supports and optionally the Mc interface trace value if requested from the 
HLR. The content of the trace records generated in the MSC server and the MGW will follow the rules of 3GPP TS 
32.421[34] and 3GPP TS 32.422[35], 3GPP TS 32.423 [36]. The content of the MGW and MSC Server trace record is 
described in TS 32.423 [36]. 

1 4. 1 Customized Alerting Tone 

14.10.1 General 

Customised Alerting Tone may be provided from a "CAT Server" switched into the call at appropriate trigger points. 
The "CAT Server" is out of the scope of the 3GPP architecture and therefore the signalling procedures towards the CAT 
Server (if not collocated) are not described. 

The Forward CAT indicators and Backward CAT indicators information elements are specified in 3GPP TS 29.205 
[22]. 

The following sub-clauses describe extensions to basic call handling and unless expUcit exceptions are made all basic 
call protocol handling support is unchanged. 

14.10.2 Audio CAT 

14.10.2.1 Audio CAT Activated by tine Calling Party 

If the calling party subscriber has activated the CAT service (CAT- A) for audio and the subscriber is in its Home 
PLMN and the calling party subscriber gives priority to CAT- A, the originating MSC Server supporting the audio CAT- 
A service shall connect that calling party UE towards the CAT Server during alerting phase. The MSC Server is 
responsible for switching the user plane towards the CAT Server during alerting phase and then on receipt of answer 
message from the called party the MSC Server shall switch the user plane towards the called party and releasing the 
coimection to the CAT Server. 

The originating MSC may indicate the CAT priority to the terminating network by setting the CAT Priority indicator of 
the Forward CAT indicators information element when sending an lAM to the succeeding node. 
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If the calling party subscriber supports CAT-A but gives priority to CAT-B and the originating MSG receives an ACM 
or CPG from the succeeding network with the CAT content Indicator in the Backward CAT indicators information 
element set to "inband media content available" then it shall not switch the user plane towards the CAT Server. If 
however the originating MSC does not receive an indication that CAT-B is present then it shall switch the user plane 
towards the CAT server as described above for the CAT-A priority case. 

NOTE: Providing alerting tone at the calling party rather than from the called party network can cause voice 

clipping if the called party answers and speaks while the calling party network has not disconnected the 
inband alerting tone. 

14.10.2.2 Audio CAT Activated by the Called Party 

If the called party subscriber has activated the CAT service (CAT-B) for audio, the GMSC Server supporting the audio 
CAT-B service shall check the CAT Priority indicator if the Forward CAT indicators information element is received. If 
CAT-A priority is requested the GMSC Server shall handle the call in accordance with normal call handling not 
supporting CAT-B service. If no CAT-A priority is received the GMSC Server shall connect the calling party network 
to the CAT Server during alerting phase. The GMSC Server should indicate in ACM or CPG message if CAT-B is 
inserted by setting the CAT content Indicator in the Backward CAT indicators information element. The GMSC Server 
is responsible for switching the user plane towards the CAT Server during alerting phase and then on receipt of answer 
message from the called party the GMSC Server shall switch the user plane towards the called party and releasing the 
connection to the CAT Server. 

14.10.3 Multimedia CAT 

14.10.3.1 Introduction 

The following subclauses specify the mobile originated and mobile terminated multimedia call procedures to generate a 
multimedia CAT to a UE supporting the multimedia CAT capabihty. 

A UE supporting multimedia CAT will indicate support of this capabihty to the MSC server as specified in 3GPP TS 
24.008 [4]. 

To play a multimedia CAT to such a UE, upon receiving the indication that the called party is being alerted and that a 
multimedia CAT is available, the MSC Server supporting multimedia CAT shall request the MGW to both-way 
through-connect the bearer towards the source of the multimedia CAT using the Change Through-Connection 
procedure, and then request the calling UE to attach to the user connection for multimedia as soon as an appropriate 
channel in multimedia mode is available and to set up an H.324 call by indicating "inband multimedia CAT available" 
within an ALERTING message or a PROGRESS message as specified in 3GPP TS 24.008 [4] subclause 5.3.6.4. 

14.10.3.2 Multimedia CAT Activated by the Calling Party 

If the calling party subscriber has activated CAT service (CAT-A) for multimedia and the subscriber is in its Home 
PLMN and the calling party subscriber gives priority to CAT-A, the originating MSC Server supporting multimedia 
CAT-A service for multimedia it shall connect that calling UE towards the CAT Server during alerting phase. The MSC 
Server is responsible for switching the user plane towards the CAT Server during alerting phase and then on receipt of 
answer message from the called party the MSC Server shall switch the user plane towards the called party and release 
the connection to the CAT Server. 

The originating MSC may indicate CAT-A has priority to the terminating network by setting the CAT Priority indicator 
of the Forward CAT indicators information element to 'Priority given to Calling party (CAT-A)' when sending an lAM 
to the succeeding node. 

NOTE: As the Forward CAT indicators information element is required to be sent by the originating MSC with 
the Multimedia CAT capability Indicator set to to "MCAT supported" if it permits multimedia CAT-B, 
the inclusion of the Forward CAT indicators information element is not strictly required since if no CAT 
parameters are included it has the same effect as indicate CAT-A has priority however it does provide 
expUcit indication that the calling party supports CAT-A. 

If CAT-B is given priority then the Multimedia CAT capability Indicator of the Forward CAT indicators information 
element shall be set as described in subclause 14.10.3.3.1. 
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If the calling party subscriber supports CAT-A but gives priority to CAT-B and the originating MSG receives an ACM 
or CPG from the succeeding network with the CAT content Indicator in the Backward CAT indicators information 
element set to "inband media content available" then it shall not switch the user plane towards the CAT Server and shall 
follow the procedures defined in subclause 14.10.3.3.1. If however the originating MSC does not receive an indication 
that CAT-B is present then it shall switch the user plane towards the CAT server as described above for the CAT-A 
priority case. 

14.10.3.3 Multimedia CAT Activated by the Called Party 

1 4.1 0.3.3.1 Mobile originated multimedia call 

If the calling UE supports the multimedia CAT service and no CAT-A priority exists, the originating MSC supporting 
the multimedia CAT service shall inform the succeeding node that multimedia CAT is supported by setting the 
Multimedia CAT capability Indicator of the Forward CAT indicators information element to "MCAT supported" in the 
lAM message sent to the succeeding node. 

The MSC Server supporting the multimedia CAT service shall consider that a multimedia CAT is available if it receives 
an ACM or CPG message including the Multimedia CAT content Indicator in the Backward CAT indicators 
information element set to "inband media content available". 

1 4.1 0.3.3.2 Mobile terminated multimedia call 

If the called party subscriber supports the "CAT-B" service for multimedia and if the GMSC Server supporting the 
optional CAT-B service for multimedia receives the Multimedia CAT capability Indicator in the Forward CAT 
indicators information element set to "MCAT supported" in the lAM from the preceding node, the GMSC Server shall 
coimect the calling party to the CAT Server during the alerting phase. 

To play a multimedia CAT to the calUng subscriber, upon receiving the indication that the called party is being alerted, 
the GMSC supporting multimedia CAT shall request the MGW to establish, and both-way through-coimect, a bearer 
cormection towards a CAT Server. 

The GMSC shall inform the originating MSC that a multimedia CAT is available (if any) by setting the Multimedia 
CAT content Indicator of the Backward CAT indicators information element to "inband media content available" in the 
ACM or CPG message. 

14.10.3.3.3 Example 

Figure 14.10.3.3.3.1 shows the message sequence chart example for providing multimedia CAT activated by the called 
party during a basic multimedia call establishment. In the example, the calling UE, the originating MSC and GMSC 
support the multimedia CAT capabiUty. 

The calling UE initiates a multimedia call establishment during which it indicates that it supports multimedia CAT 
capability (bullet 1). The originating MSC sends an Initial Address message to the GMSC of the called party indicating 
that Multimedia CAT is supported. 

The GMSC server determines that the called party has a multimedia CAT subscription (bullet 6) e.g. based on OSS 
code retrieved from the HLR. 

Upon receiving the indication that the called party is being alerted, the GMSC sets up a UDI call towards the CAT 
Server. Upon reception of an Address Complete message from the CAT server, it returns to the originating MSC an 
Address Complete or Call Progress message indicating that multimedia CAT is available (bullet 13). This leads the 
originating MSC to request the calUng UE (supporting multimedia CAT) to attach to the user connection and to set up a 
H.324 call to the CAT server (buUet 14). 

When the called party accepts the call, the GMSC releases the call towards the CAT server (bullet 18), waits for the 
Release Complete message from the CAT Server, and then through-connects the calling and called legs and returns an 
answer indication to the originating MSC. 

Upon reception of the CONNECT message, the calling UE releases any on-going H.324 call and establishes a new 
H.324 call towards the called party. 
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Figure 14.10.3.3.3.1: lUluitimedia CAT during a multimedia mobile originated call (message sequence 

chart) 
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15 Tunnelling 

NOTE: All message sequence charts in this clause are examples. AU vahd call establishment message sequences 
can be derived from the example message sequences and associated message pre-conditions. 

15.1 Forward Bearer Establishment 

The following clauses describe the requirements for tunnelhng transport mechanism within the bearer independent CS 
core network. These requirements are supplementary to those already stated in the Call Establishment clause. If 
out of-band transcoder control is apphed for a speech call, it shall be performed in accordance with 
3GPPTS 23.153 [3]. 

15.1.1 Outgoing Side 

15.1.1.1 Tunnel Selection 

If the MGW selection occurs before the lAM is sent, the (G)MSC server uses the Prepare Bearer procedure to indicate a 
tunnel support to the MGW. Depending upon the received value, the MGW shall determine whether tunnelling shall 
actually be used and when to send the tuimel data (bullet 1 in figure 15.2). 

If the (G)MSC server indicated that tuimelling is not supported, the bearer will be established as described in 
clause Call Establishment. 

If the (G)MSC server indicated that fast tunnelling is supported, the MGW may select which tuimelling method to use. 
In this case the MGW shall select either fast tunnelling or the non-tunnelhng method. 

If the (G)MSC server indicated that delayed tunnelling is supported, the MGW may select which tunnelhng method to 
use. In this case the MGW shall select either delayed tunnelling or the non-tunnelling method. 

If the MGW is allowed to choose whether tunnelling is to be used, it shall select either fast, delayed, or the 
non-tunnelling method. 

The MGW shall respond to the Prepare Bearer procedure with the used tunnel indication, when the type of tunnelling 
mechanism has been decided. 

NOTE: For a given bearer type, other specifications may describe the mechanism to be used to transport bearer 
control information. An MGW is only required to comply with that specification. 

15.1.1.2 Initial addressing 

If the MGW selection has occurred, the MGW shall respond to the Prepare Bearer procedure indicating whether 
tunnelling is allowed and what type of tunnelling is used - fast or delayed forward. The (G)MSC server provides a 
tunnel indicator to the succeeding node in the lAM to indicate that tunnelling is to be used. For fast tunnelling, the 
(G)MSC server waits for the MGW to use the Tunnel Information Up procedure to provide the tunnel data before the 
lAM is sent. 

If the MGW indicates that tuimelhng is not to be used, then tuimel indicator is not included in the Initial Address 
message and the bearer will be estabhshed as described in clause Call Estabhshment. 

If the MGW has not been selected yet, then the (G)MSC server decides whether delayed tunnelling is supported or not. 
If the delayed tunnelling is supported the tunnel indicator is included to the Initial Address message to indicate that. 
Otherwise the tunnel indicator is not included to the Initial Address message and the bearer will be established as 
described in clause Call Establishment. 

15.1.1.3 Fast forward tunnelling 

The tunnel data is transferred in the lAM and the subsequent Tunnel Information message(s). 
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Before the lAM is sent, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to supply 
the tunnel data. The (G)MSC server sends the received tunnel data to the succeeding node in the lAM (bullet 2 in 
example, clause 15.2). 

When the (G)MSC server receives a Tunnel Irrformation message from the succeeding node the (G)MSC server uses the 
Tunnel Information Down procedure to supply the MGW with the received tunnel data (bullet 5 in example 
sequence 15.2). 

1 5. 1 . 1 .4 Delayed forward tunnelling 

The tunnel data is transferred in the Tunnel Information messages following the Bearer Information message. 

If tunnel indicator was included in the lAM indicating that delayed tunnelling is supported, the succeeding node may 
include the tunnel indicator to the Bearer Information message. If the tunnel indicator is received the (G)MSC server 
indicates the delayed tunnel support in the Establish Bearer procedure. 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the succeeding node. 

When the (G)MSC server receives a Tunnel Information message from the succeeding node, the (G)MSC server uses 
the Tunnel Information Down procedure to send the received tunnel data to the MGW. 

1 5. 1 . 1 .5 Bearer control signalling transfer 

The tunnelling of the bearer control signalling is transported transparently through the (G)MSC server during the call 
establishment and at any other time until Release is sent or received. 

15.1.2 Incoming Side 

15.1.2.1 Initial addressing 

The (G)MSC server receives the possible tunnel indicator and the tunnel data in lAM. Based on received information it 
provides the turmel support indication and the tunnel data to the MGW. 

1 5.1 .2.2 Tunnel Selection 

If the tunnel indicator was received in the lAM, the (G)MSC server uses the received tunnel indicator to indicate the 
support of tunnel to the MGW. If the tunnel indicator is received in the lAM without tunnel data, the (G)MSC server 
checks the value of the tunnel indicator. If the tunnel indicator indicates that tunnel mechanism is to be used then 
delayed tuimelling is indicated to the MGW. If the turmel indicator indicates that tunnel mechanism is supported the 
(G)MSC server decides whether the delayed tunnel is supported or non tunnelhng mechanism is used. If both tunnel 
indicator and tunnel data are received in the lAM, fast tunnelling is indicated to the MGW. 

If no tunnel indicator was received in the lAM, then the preceding node has indicated that non-tunnelling mechanism is 
to be used. 

The (G)MSC server uses the Prepare Bearer procedure to supply the tunnel support indication to the MGW. 

The MGW decides based on the received tunnel support indication from the (G)MSC server whether to use delayed 
tunnelling or not. In the response the MGW provides the used tunnel indication to the (G)MSC server. 

1 5. 1 .2.3 Fast forward tunnelling 

The tunnel data is transferred in the lAM and the subsequent Tunnel Iirformation message(s). 

The (G)MSC server sends the tunnel data received in the lAM to the MGW using the Tunnel Information Down 
procedure (buUet 3 in example, clause 15.2). 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the preceding node (bullet 4 in example, clause 15.2). 
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1 5.1 .2.4 Delayed forward tunnelling 

The tunnel data is transferred in the Tunnel Information messages following the Bearer Information message. 

If tunnel indicator was received in the lAM indicating that delayed tunnel is supported and delayed tunnelling was 
indicated by the MGW, the (G)MSC server shall include the tunnel indicator to the Bearer Information message which 
is sent to the preceding node. 

When the (G)MSC server receives a Tunnel Information message from the preceding node, the (G)MSC server uses the 
Tunnel Information Down procedure to send the received tunnel data to the MGW. 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the preceding node. 



1 5.1 .2.5 Bearer control signalling transfer 

The tunnelling of bearer control signalling is transported transparently during the call establishment and at any other 
time until Release is sent or received. 



15.1.2.6 Example 

Figure 15.1 shows the network model for the forward tunnelling transport mechanism. The "squared" line represents the 
call control signalling. The "dotted" line represents the bearer control signalling. The (G)MSCa seizes one context with 
two bearer terminations in MGWa. The bearer termination Tl is used for the bearer towards the incoming side of 
(G)MSCa and the bearer termination T2 is used for the tunnelling towards the succeeding MGW. The (G)MSCb seizes 
one context with two bearer terminations in MGWb. The bearer termination T3 is used for the bearer towards the 
outgoing side of (G)MSCb and the bearer termination T4 is used for the tunnelling towards the preceding MGW. 
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Figure 15.1 : Forward Tunnelling Transport Mechanism (network model) 

Figure 15.2 shows the message sequence example for fast forward tunnelling transport mechanism. In the example 
(G)MSCa indicates to MGWa that fast tunnelling is requested. After MGWa has notified the (G)MSCa of the tunnel 
data, the lAM is sent to the (G)MSCb. The (G)MSCb indicates to MGWb that fast tunnelling is supported and sends the 
received tunnel data to MGWb. Once MGWb has sent the tunnel data to the (G)MSCb, the (G)MSCb sends a Tunnel 
Information message with the tunnel data to the (G)MSCa. The (G)MSCa sends the received tunnel data to MGWa. The 
handling of Continuity message, through-connection and answer is as normal for non-tunnelled forward bearer 
establishment. 
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Figure 15.2: Fast Forward Tunnelling Transport Mechanism (message sequence chart) 



15.2 Backward Bearer Establishment 

The following clauses describe the additional requirements for tunnelling transport mechanism within the bearer 
independent CS core network. If out-of-band transcoder control is appUed for a speech call, it shall be performed in 
accordance with 3GPP TS 23.153[3]. 



15.2.1 Outgoing Side 
15.2.1.1 Tunnel Selection 

The (G)MSC server uses the Prepare Bearer procedure to indicate a tunnel support to the MGW. Depending upon the 
received value, the MGW shall determine whether tunnelhng shall actually be used and when to send the tunnel data 
(bullet 1 in example, clause 15.4). 

If the (G)MSC server indicated that tunnelling will be not supported, the bearer is estabUshed as described in clause 
Call EstabUshment. 

If the (G)MSC server indicated that fast tunnelling is supported, the MGW may select which tunnelhng method it can 
use. In this case the (G)MSC may select either fast tunnelling or the non-tunnelling method. 

If the (G)MSC server indicated that delayed tunnelling is supported, the MGW may select which tunnelling method it 
can use. In this case the (G)MSC server may select either delayed tunnelling the non-tunnelling method. 

If the MGW is allowed to choose whether tunnelling is to be used, it shall select either fast, delayed or the 
non-tunnelling method. 
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After MGW has decided which tuimelUng mechanism to use , it responds to the Prepare Bearer procedure with the used 
tunnel indication. 

15.2.1.2 Initial addressing 

The MGW shall respond to the Prepare Bearer procedure to indicate whether tunnelling is allowed and what type of 
tunnelling is used - fast or delayed forward. The (G)MSC server provides a tunnel indicator to the succeeding node in 
the lAM. For fast tunnelling, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to 
provide the tuimel data before the lAM is sent. 

If the MGW indicates that tuimelUng is not to be used, the bearer will be established as described in clause Call 
EstabUshment. 

1 5.2.1 .3 Fast forward tunnelling 

The tunnel data is transferred in the lAM and the subsequent Tunnel Information message(s). 

Before the lAM is sent, the (G)MSC server waits for the MGW to use the Tunnel Information Up procedure to supply 
the tunnel data. The (G)MSC server sends the received tunnel data to the succeeding node in the lAM. 

When the (G)MSC server receives a Tunnel Information message from the succeeding node the (G)MSC server uses the 
Tunnel Information Down procedure to supply the MGW with the received tuimel data. 

1 5.2.1 .4 Delayed backward tunnelling 

The tuimel data is transferred in the Tunnel Information messages following the lAM. 

When the (G)MSC server receives a Tunnel Information message from the succeeding node the (G)MSC server uses the 
Tunnel Information Down procedure to supply the MGW with the received tunnel data (bullet 4 in example, 
clause 15.4). 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the succeeding node (bullet 5 in example, clause 15.4). 

15.2.1.5 Bearer control signalling transfer 

The tunnelling of bearer control signalling is transported transparently through the (G)MSC server during the call 
establishment and at any other time until Release is sent or received. 

15.2.2 Incoming Side 

15.2.2.1 Initial addressing 

The (G)MSC server receives the possible tunnel indicator and the tunnel data in the lAM. Based on received 
information it provides the tunnel support indication and the tunnel data to the MGW. 

15.2.2.2 Tunnel Selection 

If the tunnel indicator was received in the lAM, the (G)MSC server uses the received tunnel indicator to indicate the 
support of tunnel to the MGW. If the tunnel indicator is received in the lAM without tunnel data, delayed tunnelling is 
indicated to the MGW. If tunnel indicator and tunnel data are received in the lAM, fast tunnelling is indicated to the 
MGW. 

The (G)MSC server uses the Establish Bearer procedure to supply the tunnel support indication to the MGW (bullet 2 in 
example, clause 15.4). 

1 5.2.2.3 Fast forward tunnelling 

The tunnel data is transferred in the lAM and the subsequent Tunnel Information message(s). 
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The (G)MSC server sends the tunnel data received in the lAM to the MGW using the Tunnel Information Down 
procedure. 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the preceding node. 

15.2.2.4 Delayed backward tunnelling 

When the MGW sends the Tunnel Information Up procedure, the (G)MSC server sends the received tunnel data in the 
Tunnel Information message to the preceding node (bullet 3 in example, clause 15.4). 

When the MGW receives an Nb User Plane Initialisation message (bullet 5a in example sequence 15.4). before the 
subsequent Tunnel Information Down procedure (bullet 6 in example sequence 15.4) , t he MGW may acknowledge 
this Nb User Plane Initialisation message without waiting for the Tunnel Information Down procedure, and send the 
acknowledge message towards the IP address and port that were supplied as source within the IP packet transporting the 
Nb User Plane Initialisation message (bullet 5b in example sequence 15.4). The MGW shall use the same RTP Payload- 
Type number for the acknowledge message, which was used in the RTP header of the packet transporting the Nb User 
Plane Initialisation message. 

Alternatively, when the MGW receives an Nb User Plane Initialisation message (bullet 5a in example sequence 15.4). 
before the subsequent Tunnel Information Down procedure (bullet 6 in example sequence 15.4), the MGW may wait for 
the Tunnel Information Down procedure, before sending the Nb User Plane Initialisation acknowledge message (bullet 
6a in example sequence 15.4). While waiting for the Tunnel Information Down procedure, the MGW may receive 
repetition(s) of the Nb User Plane Initialisation message and shall not treat this as error case. 

When the (G)MSC server receives a Tunnel Information message from the preceding node, the (G)MSC server uses the 
Tunnel Information Down procedure to send the received tunnel data to the MGW (bullet 6 in example, clause 15.4). 

After receiving the Tunnel Information Down procedure (bullet 6 in example sequence 15.4) and acknowledging the 
NbFP Init message (bullet 5b or 6a in example sequence 15.4), the MGW shall notify the MSG server about the bearer 
establishment (bullet 7 in example sequence 15.4). 

1 5.2.2.5 Bearer control signalling transfer 

The tunnelling of bearer control signalling is transported transparently through the (G)MSC server during the call 
establishment and at any other time until Release is sent or received. 

15.2.2.6 Example 

Figure 15.3 shows the network model for the backward delayed tunnelling transport mechanism. The "squared" line 
represents the call control signalling. The "dotted" line represents the bearer control signalling. The (G)MSCa seizes 
one context with two bearer terminations in MGWa. The bearer termination Tl is used for the bearer towards the 
incoming side of (G)MSCa and the bearer termination T2 is used for the tunnelling towards the succeeding MGW. The 
(G)MSCb seizes one context with two bearer terminations in MGWb. The bearer termination T3 is used for the bearer 
towards the outgoing side of (G)MSCb and the bearer termination T4 is used for the tunnelling towards the preceding 
MGW. 
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Figure 15.3: Delayed Backward Tunnelling Transport Mechanism (network model) 
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Figure 15.4 shows the message sequence example for backward tunnelling transport mechanism. In the example the 
(G)MSCa indicates to MGWa that delayed tunnelling is requested. After MGWa has responded the (G)MSCa of 
tunnelling, the 1AM is sent to (G)MSCb. The (G)MSCb indicates to MGWb that delayed tunnelling is supported. Once 
MGWb has sent the tunnel data to the (G)MSCb, the (G)MSCb sends the received tunnel data in the Tunnel 
Information message to the (G)MSCa. The (G)MSCa sends the received tunnel data to MGWa. Once MGWa has sent 
the tunnel data to the (G)MSCa, the (G)MSCa sends the received tunnel data in the Tunnel Information message to the 
(G)MSCb. The (G)MSCb sends the received tunnel data to MGWb. The handUng of Continuity message, through- 
connection and answer is as normal for non-tunneUed backward bearer estabhshment. 
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Figure 15.4: Delayed Backward Tunnelling Transport Mechanism (message sequence chart) 



1 6 Messages/Procedures and their contents 

This clause contains the detailed description of the information flows used in bearer independent CS core network. 
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Each Information Element, IE, is marked as (M) Mandatory, (C) Conditional or (O) Optional. A mandatory information 
element shall always be present. A conditional information shall be present if certain conditions are fulfilled; if those 
conditions are not fulfilled it shall be absent. An optional information element may be present or absent, at the 
discretion of the apphcation at the sending entity. This categorisation is a functional classification, i.e., stage 2 
information and not a stage 3 classification to be used for the protocol. 

The stage 2 and stage 3 message and information element names are not necessarily identical. 

16.1 Messages between (G)MSC servers 

Table 16.1 indicates messages between (G)MSC servers in Nc interface. Only the new messages and information 
elements required by the bearer independent CS core network are shown. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 214 ETSI TS 123 205 V9.2.0 (2011-04) 



Table 16.1 : Messages between (G)MSC servers 



Message 


Message 
direction 


Information element 
name 


Information 
element 
required 


Information element description 


Initial Address 


Forward 


Bearer Establishment 
Direction 


M 


This information element indicates that the 
direction of bearer establishment. 






Bearer Address 


C 


This information element indicates the bearer 
address of the MGW used by the preceding 
node. This information element is included 
when an AAL2 bearer is establish ed using 
backward bearer establishment control 
protocol. Othenwise the information element 
is optional. 






Binding Reference 


C 


This information element indicates the bearer 
identifier in the MGW used by the preceding 
node. This information element is included 
when an AAL2 bearer is established using 
backward bearer establishment control 
protocol. Otherwise the information element 
is optional. 






MGW-id 





This information element indicates the MGW 
selected by the preceding node. 






Bearer Characteristics 


M 


This information element indicates the 
characteristics of the bearer. 






Tunnel Indicator 





This information element indicates either that 
tunnelling is to be used or tunnelling is 
supported. 






Tunnel data 





This information element contains the tunnel 
data that is provided between MGWs. 


Bearer Information 


Backward 


Bearer Address 


C 


This information element indicates the bearer 

address of the MGW used by the succeeding 
node. This information element is included 
when an AAL2 bearer is established using 
forward bearer establishment control 
protocol. Othenwise the information element 
is optional. 






Binding Reference 


C 


This information element indicates the bearer 
identifier in the MGW used by the succeeding 
node. This information element is included 
when an AAL2 bearer is established using 
forward bearer establishment control 
protocol. Otherwise the information element 
is optional. 






MQW-ld 


o 


This information element indicates the MGW 
selected by the succeeding node. 






Tunnel Indicator 


o 


This information element indicates that 
tunnelling is used. 












Tunnel Information 


Both 


Tunnel Indicator 


M 


This information element indicates that the 

message contains tunnelling information. 






Tunnel data 


M 


This information element contains the tunnel 
data that is provided between MGWs. 


Start DTMF 


Both 


Start DTMF Indicator 


M 


This information element indicates that the 
message is useo lor oian u i Mr. 






Digit 


M 


This information element indicates the digit 
for DTMF tone generation. 


Start DTMF Ack 


Both 


Start DTMF Ack 
indicator 


M 


This information element indicates that the 
message is used for Start DTMF Ack. 


Stop DTMF 


Both 


Stop DTMF indicator 


M 


This information element indicates that the 
message is used for Stop DTMF. 


Stop DTMF Ack 


Both 


Stop DTMF Ack 
indicator 


M 


This information element indicates that the 
message is used for Stop DTMF Ack. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



215 



ETSI TS 123 205 V9.2.0 (2011-04) 



16.2 Procedures between (G)MSC server and MGW 

The clauses below indicate the procedures used between (G)MSC server and MGW in Mc interface. The procedures are 
logical, i.e. message identifiers are not part of the protocol. Several logical procedures can be combined into one H.248 
command in order to perform required transactions. If several logical procedures are combined, only one 
context/context request and only one bearer termination/bearer termination request is sent in the H.248 command. 
Exemption is the Change Flow Direction procedure, where the two bearer terminations are related to a change of the 
context and not to a command of the bearer termination. All the procedures below describe a successful operation. If the 
procedure is rejected, a Command Reject is sent back to the entity that sent the command request. 

16.2.1 Change Flow Direction 

This procedure is used to change the flow direction between bearer terminations within the context. 



Table 16.2: Procedures between (G)MSC server and MGW: Change Flow Direction 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Change Flow 
Direction 


(G)MSC-S 


Context/Context 
Request 


M 


This information element indicates the 
existing context or a new context where the 
flow direction is changed. 


Bearer Termination 1/ 
Bearer Termination 1 
Request 


M 


This information element indicates the 
existing bearer termination or a new bearer 
termination from where the new flow direction 
is applied. 


Bearer Termination 21 
Bearer Termination 2 
Request 


M 


This information element indicates the 

existing bearer termination or a new bearer 
termination where to the new flow direction is 
applied. 


Flow Direction 


M 


This information element indicates the flow 
direction from the bearer termination 1 to 
bearer termination 2 within the context. 


Cliange Flow 
Direction Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



NOTE 1: This procedure may be combined with Prepare Bearer, Prepare_IP_Transport, Establish Bearer, Reserve 
Circuit, Reserve RTP Connection Point, Configure RTP Connection Point or Reserve and Configure RTP 
Connection Point, Join Bearer Termination or Isolate Bearer Termination procedure. This list of 
procedures is not exhaustive. 

NOTE 2: Only one of the bearer terminations can be a new bearer termination within this procedure. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 216 ETSI TS 1 23 205 V9.2.0 (201 1 -04) 

16.2.2 Join Bearer Termination 

This procedure is used to join a bearer termination with other bearer terminations within the context. 



Table 16.3: Procedures between (G)MSC server and MGW: Join Bearer Termination 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Join Bearer 
Termination 


(G)MSC-S 


Context 


M 


This information element indicates tlie 
context where the bearer termination is 

joined. 


Bearer 
Termination/Bearer 
Termination Request 


IVI 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination to be joined with the other 

bearer terminations within the context. 


Join Bearer 
Termination Acl< 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.3 Isolate Bearer Termination 

This procedure is used to isolate one bearer termination from the other bearer terminations within the context. 
Table 16.4: Procedures between (G)MSC server and MGW: Isolate Bearer Termination 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


Isolate Bearer 
Termination 


(G)MSC-S 


Context/Context 
Request 


M 


This information element indicates the 
existing context or a new context where to 
the bearer termination is isolated. 


Bearer 

Termination/Bearer 
Termination Request 


M 


This information element indicates the 

existing bearer termination or requests a new 
bearer termination to be isolated from the 
other bearer terminations within the context. 


Isolate Bearer 
Termination Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.4 Establish Bearer 

This procedure is used to request a bearer establishment. 



Table 16.5: Procedures between (G)MSC server and MGW: Establish Bearer 



Procedure 


Initiated 


II IIUI IlldllUI 1 Cidlldll 

name 


II IIUI iiidliui 1 

element 
required 


II IIUI IlldllUI 1 cidlldll UC9l#l lUllUI 1 


Establish Bearer 
(G)MSC-S 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context for 
the bearer termination. 


Bearer 
Termination/Bearer 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination for the bearer to be 
established. 


Bearer Establishment 

Request 


M 


This information element requests 
establishment of a bearer. 


Destination Bindincj 
Reference 




This information element indicates the bearer 
identifier in the destination MGW. This 
information element shall be included when 
requesting the establishment of an AAL2 
bearer. Otherwise the information element is 
optional. 


Destination Bearer 
Address 


c 


This information element indicates the bearer 
address of the destination MGW. This 
information element shall be included when 
requesting the establishment of an AAL2 
bearer. Otherwise the information element is 
optional. 


Bearer Characteristics 


M 


This information element indicates the 
characteristics of the bearer connection. 


Bearer Service 
Characteristics 




This information element indicates the bearer 
service requested by the user. This 
information element is not included if the 
Codec information element is provided. It 
may be included for a non-speech / non 
SCUDIF multimedia call (see3GPP TS 
23.172 [38], 3GPP TS 29.007 [37] and 3GPP 
TS 29.232 [6]). 


Notify Bearer Event 





This information element requests a 
notification of an established bearer, a 
released bearer, a modified bearer or a bearer 
modification failure. 


Tunnel Support 





This information element indicates the 
support of tunnel data transfer and when to 
send tunnel data. In 29.232 this information 
element is defined in the Tunnel Information 
down procedure. 


Circuit Switched Data 


c 


This information element indicates the 
PLMN bearer capabilities and when 
appUcable GSM channel coding. This 
information element shall be included 
according to 3GPP TS 29.007 [37] and 3GPP 
TS 29.232 [6] for a non-speech / non 
SCUDIF multimedia call (see 3GPP TS 
23.172 [38])by the MSC server, or by the 
anchor-MSC in case of inter-MSC handover, 
for an anchor MGW network termination. 
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Codec 


C 


This information element indicates the 
speech coding format to be used for the 
bearer. This information element is included 
for a speech call for a network side bearer 
termination. 


Framing Protocol 





This information element indicates the 
framing protocol to be used for the bearer. 


Call Type 
Discrimination 





This information element supports modem 
signalUng for GTT feature. 

NOTE 


Text Telephone 





This information element supports 
interworking with PSTN text telephone. 
NOTE 


Notify termination 
heartbeat 


c 


This information element requests 
termination heartbeat indications. This 
information element shall be included when 
requesting a new bearer termination. 
Otherwise the information element is 
optional. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Number of desired 

li^tpnpr pnntPYt 

IIOICI ICI LfUl IIC7AL 

terminations 





This information element indicates the 
number of desired terminations for a listener 
context in a VGCS or VBS call. It should be 
included in the first ADD request which 
estabUshes a Listener context. 


Establish Bearer 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 

executed. 


NOTE: Procedures for use of Text Telephony indication and Call Type discrimination are not defined. 
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16.2.5 Prepare Bearer 

This procedure is used to prepare for a bearer establishment. 



Table 16.6: Procedures between (G)MSC server and MGW: Prepare Bearer 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Prepare Bearer 
(G)MSC-S 


Context/Context 
Request 


IVI 


This information element indicates the 
existing context or requests a new context for 
thp hparpr tprmin^tinn 

LI i\S v^l Iv^l 1 1 III IdllUI 


Bearer Termination 


IVI 


This information element requests a new 
hparpr* tprmlnfltinn fnr thp hparpr tn l^p 

Wdl CI ICI 1 1 III luLIUI 1 l\JI LI IC UCCll d l.\J k^C 

established. 


Binding Reference 
Request 


c 


This information element requests the bearer 
identifier in the IVIGW. This information 
element shall be included when preparing the 
establishment of an AAL2 bearer. Otherwise 
the information element is optional. 


Bearer Address 
Request 


c 


This information element requests the bearer 
address of the IVIGW. This information 
element shall be included when preparing the 
establishment of an AAL2 bearer. Otherwise 
the information element is optional. 


Rpnrlpr Rinriinn 

^^wl lUwl L^ll lull lU 

Reference 





ThI*? infnrmatinn pjpmpnt inriiratp'? thp hparpr 

IIIIO Mil \J III 1 CiLIU 1 1 W 1 wl 1 1 Wl 1 L II lU 1 wCiLw O LI 1 w v wCLI w 1 

identifier of the sending MGW. 


Sender Bearer 
Address 





This information element indicates the bearer 
address of the sending IVIGW. 


Rparpr Ohflrflrtpri<;tir<5 

LJCCll d \JI ICll ClLrLd lOll^O 


M 


Thic? infnrmfltinn pipmpnt inrlipatp*^ thp 

1 IIIO IlllWIIIIdllliJII ^1^11 1^1 IL lll\.JI\..rClL^O Lll^ 

requested characteristics of the bearer 
connection. 


Bearer Service 
Characteristics 


C 


This information element indicates the bearer 
service requested by the user. This 

1 1 1 lUM 1 IdllUi 1 UlUfllUltl lo 1 lUL IIILrlUUt^U II ii \Ki 

Codec information element is provided. It 
may be included for a data call (see 
3GPP TS 29.007 [37] and 3GPP TS 29.232 
[6]). 


Nntifx/ Rpnrpr F\/pnt 


o 


XhiQ infnrmatinn pIpmpnt rpniiPQtQ ^ 

I lllo llllVJlllldLIUII dc?iiic;iiL ic^uuc^oLo CI 

notification of an established bearer, a 
released bearer, a modified bearer or a 
bearer modification failure. 


Notify Bearer 
IVIodification 





This information element requests a 
notification that bearer modification of the 

established bearer is allowed. This 
information element may be included for 
access bearer assignment. 


Tunnel Support 





This information element indicates the 
^iinnnrt nf tiinnpl data tran^fpr and whpn tn 

OLII.^I.^^i^l L \Ji LUI II Id V_l CI L iJl Li CLI iOid CLi l\A VVi Id 1 L\J 

send tunnel data. In 3GPP TS 29.232 [6] this 
information element is defined in the Tunnel 
Information down procedure. 


Circuit Switched Data 


c 


This information element indicates the PLMN 
bearer capabilities and when applicable GSM 
channel coding and user bit rate. This 
information element shall be included 
according to 3GPP TS 29.007 [37] and 3GPP 
TS 29.232 [6] for a non-speech call by the 
MSC server, or by the anchor-MSC in case of 
inter-MSC handover, for a radio access 
network termination and for an anchor MGW 
network termination. 
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Codec 


C 


This information element indicates the 
speech or multimedia coding format to be 
used for the bearer. This information element 
is included for a speech call and may be 
included for a SCUDIF multimedia call 
(seeSGPP TS 23.172 [38], 3GPP TS 29.007 
[37] and 3GPP TS 29.232 [6]). 


Framing Protocol 





This information element indicates the 
framing protocol to be used for the bearer. 


Cellular Text telephony 
modem 


C 


This information element indicates the need 
of CTM function. 


Notify termination 

heartbeat 


M 


This information element requests 

termination heartbeat indications. 


Number of needed 
conference 
terminations 





This information element indicates the 
number of conference ports needed for that 
VGCS or VBS call. It shall be included in the 
first ADD request which establishes the 
Multiparty context. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Prepare Bearer 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination where the command was 

executed. 


Binding Reference 


c 


This information element indicates the bearer 
identifier in the MGW. This information 
element is included if requested in the 
Prepare Bearer request. 


Bearer Address 


c 


This information element indicates the bearer 
address of the MGW. This information 
element is included if requested in the 
Prepare Bearer request. 
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16.2.6 Reserve Circuit 

This procedure is used to select a TDM circuit in the MGW. 



Table 16.7: Procedures between (G)MSC server and MGW: Reserve Circuit 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Reserve Circuit 
(G)MSC-S 


OnntPYt/OnntPYt 

Request 


M 


Thi<5 informptinn pipmpnt inrliP3tp<^ thp 

1 IIIO IIIIWIIIICIIIUII d^lll^lll lll\ull\.fClL^O 11 1^ 

existing context or requests a new context for 
the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
physical bearer termination for the TDM 

pirpi lit 


Circuit Switclied Data 


C 


This information element indicates the PLMN 
hparpr f^nphilitipc; anrl (^5^M phpnnpl mHinn 

This information element shall be included 
accordina to 3GPP TS 29 007 [371 and 3GPP 
TS 29.232 [6] for a non-speech call by the 
MSC server, or by the anchor-MSC in case of 
inter-MSC handover, for a radio access 
network side bearer termination. 


Bearer Service 
Characteristics 


C 


This information element indicates the bearer 
service requested by the user. This 
information element is included if no Circuit 
Switched Data information element is 

provided. 


Cellular Text telephony 
modem 


C 


This information element indicates the need 
of CTM function. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer 


Notify termination 
heartbeat 





This information element requests 
termination heartbeat indications. 


Number of desired 
listener context 
terminations 





This information element indicates the 
number of desired terminations for a listener 
context in a VGCS or VBS call. It should be 
included in the first ADD request which 
establishes a Listener context. 


Reserve Circuit 
Acl< 


MGW 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed.. 
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16.2.7 Change Through-Connection 

This procedure is used to change the through-connection in the bearer termination. 



Table 16.8: Procedures between (G)MSC server and MGW: Change Through-Connection 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Change Through- 
Connection 


(G)MSC-S 


Context/Context 
Request 


IVI 


This information element indicates the 
existing context or requests a new context for 
the bearer termination. 


Bearer 
Termination/Bearer 
Termination Request 


IVI 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination where the through- 
connection is changed. 


Through-Connection 


M 


This information element indicates the 
through-connection of the bearer termination. 


Change Through- 
Connection Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Prepare Bearer, Prepare_IP_Transport, Establish Bearer, Reserve 
Circuit, Reserve RTF Connection Point , Configure RTP Connection Point or Reserve and Configure 
RTP Connection Point, Join Bearer Termination, Isolate Bearer Termination or Release Bearer procedure. 
This Ust of procedures is not exhaustive. 



16.2.8 Activate Intenworking Function 

This procedure is used to activate the interworking function. 



Table 16.9: Procedures between (G)MSC server and MGW: Activate Interworking Function 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Activate 
Interworking 
Function 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the interworking function is 

activated. 


Circuit Switched Data 
Activate 


M 


This information element requests to activate 
the interworking function. 


Circuit Switched Data 





This information element indicates the 
request for IWF protocol negotiation result 
and rate change indication. 


Activate 
Interworking 
Function Ack 


IVIGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.9 Release Bearer 

This procedure is used to release the bearer. 



Table 16.10: Procedures between (G)MSC server and MGW: Release Bearer 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release Bearer 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination for the bearer to be released. 


Bearer Release 
Request 


M 


This information element requests release of 
a bearer. 


Release Cause 





This information element indicates the cause 
of a bearer release. 


Release Bearer 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.10 Bearer Established 

This procedure is used to notify the established bearer. 

Table 16.11 : Procedures between (G)MSC server and MGW: Bearer Established 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer 
Established 


IVIGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the bearer was 
established. 


Bearer Established 


M 


This information element notifies a bearer 
establishment. 


Bearer 
Established Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 

context where the command was executed. 


Bearer Termination 


IVI 


This information element indicates the Bearer 
Termination where the command was 
executed. 
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16.2.11 Bearer Released 

This procedure is used to notify the released bearer or failed bearer establishment. 



Table 16.12: Procedures between (G)MSC server and MGW: Bearer Released 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer Released 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the bearer was released. 


Bearer Released 


M 


This information element notifies a bearer 
release. 


Release Cause 


M 


This information element indicates the cause 
of a bearer release. 


Bearer Released 
Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 



1 6.2.1 2 Release Termination 

This procedure is used to release the bearer termination. 



Table 16.13: Procedures between (G)MSC server and MGW: Release Termination 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Release 
Termination 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 

termination to be released. 


Release 
Termination Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 

executed. 


T.140 data statistics 


C 


Number of t.140 data bits transmitted over 
the termination 
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16.2.13 Tunnel Information Up 

This procedure is used to transfer tunnel data from the MGW to the (G)MSC server. 



Table 16.14: Procedures between (G)MSC server and MGW: Tunnel Information Up 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Tunnel Information 
Up 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination from where the tunnel data is 
sent. 


Tunnel Data 


M 


This information element contains the tunnel 
data that is provided between IVlGWs. 


Tunnel 
InformationUp Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 



16.2.14 Tunnel Information Down 

This procedure is used to transfer tunnel data from the (G)MSC server to the MGW. 

Table 16.15: Procedures between (G)MSC server and MGW: Tunnel information 



Procedure 


Initiated 


information element 
name 


information 
element 
required 


information element description 


Tunnel Information 
Down 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where to the tunnel data is sent. 


Tunnel Data 


M 


This information element contains the tunnel 
data that is provided between MGWs. 


Tunnel Information 
Down 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Prepare Bearer or Establish Bearer procedure. 
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16.2.15 Send Tone 

This procedure is used to send a tone. 



Table 16.16: Procedures between (G)MSC server and MGW: Send Tone 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Send Tone 
(G)MSC-S 


Context 


IVI 


This information element indicates the 
context for the bearer termination. 


Bearer 
Termination/Bearer 
Termination Request 


IVi 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination where the tone is sent. 


Tone 


IVI 


This information element indicates the tone to 
be generated. 


Notify Tone 
Completion 





This information element requests a 
notification of a completed tone. 


Tone Direction 





This information element indicates the tone 
direction in the bearer termination. 


Tone Timing 





This information element indicates the time 
for the tone. 


Notify termination 
lieartbeat 


c 


This information element requests 
termination heartbeat indications. This 
information element shall be included when 
requesting a new ephemeral bearer 
termination. 


Send Tone Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Join Bearer Termination or Isolate Bearer Termination procedure. 



16.2.16 Stop Tone 

This procedure is used to stop the tone. 



Table 16.17: Procedures between (G)MSC server and MGW: Stop Tone 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


Stop Tone 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the tone is stopped. 


Stop Tone 


M 


This information element requests that tone 
generation is stopped. 


Stop Tone Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.17 Play Announcement 

This procedure is used to play an announcement. 



Table 16.18: Procedures between (G)MSC server and MGW: Play Announcement 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Play Announcement 
(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer 
Termination/Bearer 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination where the announcement 
is sent. 


Announcement 


M 


This information element indicates the 
announcement to be played. 


Notify Announcement 
Completion 





This information element requests a 
notification of a completed announcement. 


Announcement 
Direction 





This information element indicates the 
announcement direction in the bearer 
termination. 


Announcement Timing 





This information element indicates the time 
for the announcement. 


Notify termination 
heartbeat 


C 


This information element requests 
termination heartbeat indications. This 
information element shall be included when 
requesting a new ephemeral bearer 
termination. 


Play 
Announcement 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Join Bearer Termination or Isolate Bearer Termination procedure. 



16.2.18 Stop Announcement 

This procedure is used to stop the announcement. 



Table 16.19: Procedures between (G)MSG server and MGW: Stop Announcement 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Stop 
Announcement 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the announcement is 
stopped. 


Stop Announcement 


M 


This information element requests that 
announcement playing is stopped. 


Stop 
Announcement 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.19 Announcement Completed 

This procedure is used to notify the completed announcement. 



Table 16.20: Procedures between (G)MSC server and MGW: Announcement Completed 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Announcement 
Completed 


MGW 


Context 


IVI 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination where the announcement was 
completed. 


Announcement 

Completed 


M 


This information element indicates 
completion of the announcement. 


Announcement 
Completed Ack 


(G)MSC-S 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 



16.2.20 Tone Completed 

This procedure is used to notify the completed tone. 

Table 16.21 : Procedures between (G)MSC server and MGW: Tone Completed 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


Tone Completed 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This Information element indicates the bearer 
termination where the tone was completed. 


Tone Completed 


M 


This information element Indicates 
completion of the tone. 


Tone Completed 
Ack 


(G)MSC-S 


Context 


M 


This information element Indicates the 
context where the command was executed. 


Bearer Termination 


M 


This Information element Indicates the Bearer 
Termination where the command was 
executed. 
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16.2.21 Detect DTMF 

This procedure is used to request detection of a DTMF tone. 



Table 16.22: Procedures between (G)MSC server and MGW: Detect DTMF 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


Detect DTMF 


(G)MSC-S 


Context 


M 


This information element indicates tlie 
context for the bearer termination. 






Bearer 


M 


This information element indicates the 






Termination/Bearer 
Termination Request 




existing bearer termination or requests a new 
bearer termination where the DTMF tone 








detection is requested. 






Digit 


M 


This information element requests MGW to 
detect a DTMF tone. 


Detect DTMF Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 






Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE This procedure may be combined with Prepare Bearer, Prepare_IP_Transport, Establish Bearer, Reserve 
Circuit, Reserve RTF Coimection Foint procedure. Configure RTF Connection Foint or Reserve and 
Configure RTF Connection Foint. This Ust of procedures is not exhaustive. 



16.2.22 Stop DTMF Detection 

This procedure is used to stop detection of the DTMF tone. 



Table 16.23: Procedures between (G)MSG server and MGW: Stop DTMF Detection 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Stop DTMF 
Detection 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the DTMF tone detection is 
stopped. 


Stop DTMF Detection 


M 


This information element requests that DTMF 
tone detection is stopped. 


Stop DTMF 
Detection Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.23 Report DTMF 

This procedure is used to report a detected DTMF tone. 



Table 16.24: Procedures between (G)MSC server and MGW: Report DTMF 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


Report DTMF 


MGW 


Context 


M 


Tliis information element indicates the 
context for tlie bearer termination. 






Bearer Termination 


M 


Tliis information element indicates the bearer 
termination where the DTMF tone was 
detected. 






Digit 


M 


This information element reports the detected 
DTMF tone. 


Report DTMF Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 






Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 



16.2.24 Send DTMF 

This procedure is used to request sending of a DTMF tone. 



Table 16.25: Procedures between (G)MSC server and MGW: Send DTMF 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


Send DTMF 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer 
Termination/Bearer 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a new 
bearer termination where the DTMF tone 
generation is requested. 


Digit 


M 


This information element requests MGW to 
generate a DTMF tone. 


DTMF Tone Timing 





This information element indicates the time 
for the DTMF tone in the bearer termination. 


Send DTMF Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.25 StopDTMF 

This procedure is used to stop sending of the DTMF tone. 



Table 16.26: Procedures between (G)MSC server and MGW: Stop DTMF 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


Stop DTMF 


(G)MSC-S 


Context 


M 


This information element indicates tlie 
context for tlie bearer termination. 






Bearer Termination 


M 


This information element indicates the bearer 
termination where the DTMF tone generation 
is stopped. 






Stop DTMF 


M 


This information element requests that DTMF 
tone generation is stopped. 


Stop DTMF Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 






Bearer Termination 


M 


This information element Indicates the bearer 
termination where the command was 
executed. 



1 6.2.26 MGW Out-of-Service/ Maintenance locking 

This procedure is used to indicate that the MGW will go out of service or is maintenance locked. 

Table 16.27: Procedures between (G)MSC server and MGW: MGW Out-of-Service or Maintenance 

Locked 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


MGW Out-of- 

Servlce/ 
Maintenance 
locked 


MGW 


Context 


M 


This Information element Indicates the 
context for the command. 


Root Termination 


M 


This Information element Indicates the root 

termination for the command. 


Reason 


M 


This information element indicates the reason 
for service change. 


Method 


M 


This Information element indicates the 
method for service change. 


MGW Out-of- 
Service/ 
Maintenance 
locked Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element Indicates the root 
termination where the command was 
executed. 
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16.2.27 MGW Communication Up 

This procedure is used to indicate that the MGW is back in service. 



Table 16.28: Procedures between (G)MSC server and MGW: MGW Communication Up 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


MGW 
Communication 
Up 


MGW 


Context 


M 


This information element indicates the 
context for the command. 


Root Termination 


M 


This information element indicates the root 
termination for the command. 


Reason 


M 


This information element indicates the reason 
for service change. 


Method 


M 


This information element indicates the 
method for service change. 


MGW Communication 
Up Acl< 
(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 


(G)MSC-S Address 





This information element indicates the 
(G)MSC server signalling address to which 
the MGW should preferably attempt to re- 
register. 



16.2.28 IVIGW Restoration 

This procedure is used to indicate the MGW failure or recovery. 

Table 16.29: Procedures between (G)MSC server and MGW: MGW Restoration 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


MGW Restoration 


MGW 


Context 


M 


This information element indicates the 
context for the command. 


Root Termination 


M 


This information element indicates the root 
termination for the command. 


Reason 


M 


This information element indicates the reason 
for the service change. 


Method 


M 


This information element indicates the 
method for service change. 


MGW Restoration Acl< 
(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 


(G)MSC-S Address 





This information element indicates the 
(G)MSC server signalling address to which 
the MGW should preferably attempt to re- 
register. 
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16.2.29 MGW Register 

This procedure is used to register the MGW. 



Table 16.30: Procedures between (G)MSC server and MGW: MGW Register 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


MGW Register 


MGW 


Context 


M 


This information element indicates the 
context for the command. 






Root Termination 


M 


This information element indicates the root 
termination for the command. 






Reason 


M 


This information element indicates the reason 
for the service change. 






Method 


M 


This information element indicates the 
method for service change. 






Protocol Version 


M 


This information element indicates the 
protocol version for Mc interface requested 
by the MGW. 






Service Change Profile 


M 


This information element indicates the profile 
for the Mc interface requested by the MGW. 


MGW Register Acl< 


Context 


M 


This information element indicates the 


(G)MSC-S 






context where the command was executed. 






Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 






Protocol Version 





This information element indicates the 
protocol version for Mc interface supported 
by the (G)MSC server. 






Service Change Profile 





This information element indicates the profile 
for the Mc interface supported by the (G)MSC 
Server. 






(G)MSC-S Address 





This information element indicates the 
(G)MSC server signalling address to which 
the MGW should preferably attempt to re- 
register. 
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16.2.30 MGW Re-register 

This procedure is used to re-register the MGW. 



Table 16.31 : Procedures between (G)MSC server and MGW: MGW Re-register 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


MGW Re-register 


MGW 


Context 


M 


This information element indicates the 
context for the command. 






Root Termination 


M 


This information element indicates the root 
termination for the command. 






Reason 


M 


This information element indicates the reason 
for the service change. 






Method 


M 


This information element indicates the 
method for service change. 






Protocol Version 


M 


This information element indicates the 
protocol version for Mc interface requested 
by the MGW. 






Service Change Profile 


M 


This information element indicates the profile 
for the Mc interface requested by the MGW. 


MGW Re-register Ack 


Context 


M 


This information element indicates the 


(G)MSC-S 






context where the command was executed. 






Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 






Protocol Version 





This information element indicates the 
protocol version for Mc interface supported 
by the (G)MSC server. 






Service Change Profile 





This information element indicates the profile 
for the Mc interface supported by the (G)MSC 
Server. 






(G)MSC-S Address 





This information element indicates the 
(G)MSC server signalling address to which 
the MGW should preferably attempt to re- 
register. 



1 6.2.31 (G)MSC Server Ordered Re-register 

This procedure is used by the (G)MSC server to request the MGW to register itself. 

Table 16.32: Procedures between (G)MSC server and MGW: (G)MSC Server Ordered Re-register 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


(G)MSC Server 
Ordered Re- 
register 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the command. 


Root Termination 


M 


This information element indicates the root 
termination for the command. 


Reason 


M 


This information element indicates the reason 

for the service change. 


(G)MSC-S Address 





This information element indicates the 
(G)MSC server signalling address. 


(G)MSC Server 
Ordered Re- 
register Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 
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16.2.32 (G)MSC Server Restoration 

This procedure is used to indicate the (G)MSC server failure or recovery. 



Table 16.33: Procedures between (G)MSC server and MGW: (G)MSC Server Restoration 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


(G)MSC Server 
Restoration 


(G)IVISC-S 


Context 


M 


This information element indicates the 
context for the command. 


Root Termination 


IVi 


This information element indicates the root 
termination for the command. 


Reason 


IVI 


This information element indicates the reason 
for the service change. 


Metliod 


IVI 


This information element indicates the 
method for service change. 


(G)MSC Server 
Restoration Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 



1 6.2.33 (G)MSC Server Out of Service 

This procedure is used to indicate that (G)MSC server has gone out of service. 

Table 16.34: Procedures between (G)MSC server and MGW: (G)MSC Server Out of Service 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


(G)IVISC Server 
Out of Service 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the command. 


Root Termination 


M 


This information element indicates the root 

termination for the command. 


Reason 


M 


This information element indicates the reason 
for the service change. 


IVlethod 


IVI 


This information element indicates the 
method for service change. 


(G)I\/1SC Server 
Out of Service 
Acl< 


IVIGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates the root 
termination where the command was 
executed. 
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16.2.34 Termination Out-of-Service 

This procedure is used to indicate that physical termination(s) will go out of service. 



Table 16.35: Procedures between (G)MSC server and MGW: Termination Out-of-Service 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination Out- 
of-Service 


IVIGW 


Context 


IVI 


Ttiis information element indicates tlie 
context for the command. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination(s) for the command. 


Reason 


IVI 


This information element indicates the reason 
for service change. 


Method 


M 


This information element indicates the 
method for service change. 


Termination Out- 
of-Service Acl< 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.35 Termination Restoration 

This procedure is used to indicate that physical tenmnation(s) are back in service. 

Table 16.36: Procedures between (G)MSC server and MGW: Termination Restoration 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
Restoration 


IVIGW 


Context 


M 


This information element Indicates the 
context for the command. 


Bearer Termination 


M 


This information element Indicates the bearer 

termination(s) for the command. 


Reason 


IVI 


This information element indicates the reason 
for service change. 


IVlethod 


M 


This information element indicates the 
method for service change. 


Termination 
Restoration Acl< 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.36 Audit Value 

This procedure is used to audit values of different object(s). 



Table 16.37: Procedures between (G)MSC server and MGW: Audit Value 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


Audit Value 


(G)MSC-S 


Context 


M 


Tliis information element indicates the 
context for the command. 






Bearer Termination 


IVI 


This information element indicates the bearer 
termination(s) for the command. 






Object(s) 


IVI 


This information element indicates the 
object(s) to be audited. 


Audit Value Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 






Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 






Value(s) 


IVI 


This information element indicates the 
value(s) of the object(s). 



16.2.37 Audit Capability 

This procedure is used to audit capabilities of different object(s). 

Table 16.38: Procedures between (G)MSC server and MGW: Audit Capability 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Audit Capability 


(G)MSC-S 


Context 


M 


This information element indicates the 
context for the command. 


Bearer Termination 


M 


This information element indicates the bearer 

termination(s) for the command. 


Object(s) 


M 


This information element indicates the 
object(s) which capability is requested. 


Audit Capability 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 


Capabilities(s) 


M 


This information element indicates the 
capabilities of the object(s). 
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16.2.38 Capability Update 

This procedure is used to indicate update of an object capability. 



Table 16.39: Procedures between (G)MSC server and MGW: Capability Update 



Procedure 


Initiated 


Information element 


Information 


Information element description 






name 


element 
required 


Capability Update 


MGW 


Context 


M 


This information element indicates the 
context for the command. 






Bearer Termination 


M 


This information element indicates the bearer 
termination(s) for the command. 






Reason 


M 


This information element indicates the reason 
for service change. 






Method 


M 


This information element indicates the 
method for service change. 


Capability Update 
Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 






Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.39 Command Reject 

This command is used to reject the received command request. It may be used as response to any of the above 
procedures. 

Table 16.40: Procedures between (G)MSC server and MGW: Command Reject 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Command Reject 


Both 


Context 


M 


This information element indicates the 
context where the command was rejected. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
rejected. 


Error 


M 


This information element indicates the error 
that caused command rejection. 
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16.2.40 Activate Voice Processing Function 

This procedure is used to activate the voice processing (echo cancellation) function. 



Table 16.41 : Procedures between (G)MSC server and MGW: Activate Voice Processing Function 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Activate Voice 
Processing 
Function 


(G)MSC-S 


Context 


M 


Tliis information element indicates tlie 
context for the bearer termination. 


Bearer Termination 


IVI 


Tliis information element indicates the bearer 
termination where the voice processing 
function is activated. 


Activate Voice 
Processing Function 


M 


This information element requests to activate 
the voice processing function. 


Activate Voice 
Processing 
Function Ack 


IVIGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element Indicates the bearer 
termination where the command was 
executed. 
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1 6.2.41 Modify Bearer Characteristics 

This procedure is used to modify the bearer characteristics. 



Table 16.42: Procedures between (G)MSC server and MGW: Modify Bearer Characteristics 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element descrintion 


Modify Bearer 
Characteristics 


(G)IVISC-S 


Context 


M 


This information element indicates the 
existing context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination for the bearer to be modified. 


Bearer Service 
Characteristics 


C 


This information element indicates the bearer 
service requested by the user. This 

information element is not included if the 

f^riHor' infrirm^tinn olomont ic nrn\/iHoH It 

OUUc^Li 1 1 1 1 Ul 1 1 IClUUI 1 tJiclllCllL lo [JIUvlUUU. IL 

may be included for a data call (see 
3GPP TS 29.007 [37] and 3GPP TS 29.232 
[61). 


Circuit Switched Data 


C 


This information element indicates the PLMN 
bearer capabilities and when applicable GSM 
channel coding and user bit rate. This 
information element shall be included 
according to 3GPP TS 29.007 [37] and 3GPP 

MSG server, or by the anchor-MSC in case of 

lliLt:;l IVIOOIICtilUUVUI,IU[ (_'lvllOI dUlU dUOt^oo 

network side bearer termination and for 
network side bearer termination. 


Codec 


c 


This information element indicates the 
speech or multimedia coding format to be 
used for the bearer. This information element 
is included for the speech call and may be 
included for a SCUDIF multimedia call 
(see3GPP TS 23.172 [38], 3GPP TS 29.007 
[37] and 3GPP TS 29.232 [6])., for UMTS 
radio access network side bearer termination 
and for network side bearer termination. 


Framing Protocol 





This information element indicates the 
framing protocol to be used for the bearer. 


IVIodify Bearer 
Characteristics 
Ack 


IVIGW 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.42 Protocol Negotiation Result 

This procedure is used to inform the MSC about protocol negotiation result. 



Table 16.43: Procedures between MSC server and MGW: Protocol Negotiation Result 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


IWF Protocol 
Indication 


MGW 


Context 


M 


This information element indicates the 
existing context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination for the bearer to be modified. 


Protocol Negotiation 
result 


M 


This information element indicates the IWF 
protocol negotiation result 


IWF Protocol 
Indication Ack 


MSC 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.43 IVIGW Resource Congestion Handling - Activate 

This procedure is used to activate the congestion handling mechanism. 

Table 16.44: Procedures between (G)MSC server and MGW: MGW Resource Congestion Handling - 

Activate 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


MGW Resource 
Congestion 
Handling - 
Activate 


(G)MSC-S 


Context 


M 


This information element indicates that all 
context are applicable for the root 
termination. 


Root Termination 


M 


This information element indicates that root 
termination is where the congestion 
mechanism is activated. 


Congestion Activate 


M 


This information element requests to activate 
the congestion mechanism. 


MGW Resource 
Congestion 
Handling - 
Activate Ack 


MGW 


Context 


M 


This information element indicates that all 
context are where the command was 
executed. 


Root Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 
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16.2.44 MGW Resource Congestion Handling - Indication 

This procedure is used to inform the (G)MSC server that traffic restriction is advised. 



Table 16.45: Procedures between (G)MSC server and MGW: MGW Resource Congestion Handling - 

Indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 

KAn 1 1 i kaH 


Information element description 


MGW Resource 
Congestion 
Handling - 

Indication 


MGW 


Context 


M 


This information element indicates all context 

are applicable for the root termination. 


Root Termination 


M 


This information element indicates that root 
termination is where the congestion 
mechanism was activated. 


Reduction 


M 


This information element indicates the load 
percentage to be reduced. 


MGW Resource 
Congestion 
Handling - 

Indication Ack 


(G)MSC 


Context 


M 


This information element indicates all context 
are where the command was executed. 


Root Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 



16.2.45 Bearer IVIodification Support 

This procedure is used to notify that the estabUshed bearer can be modified. 

Table 16.46: Procedures between (G)MSC server and MGW: Bearer Modification 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer 
Modification 
Support 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the bearer was 

established. 


Bearer Modification 


M 


This information element notifies that the 
established bearer can be modified. 


Bearer 

Modification 
Support Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 

context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 
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16.2.46 CTM report 

This procedure is used to notify the outcome of the CTM negotiation in the user plane. 



Table 16.47: Procedures between (G)MSC server and MGW: CTM report 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


CTM report 


MGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the CTM function was 
activated 


Outcome of CTM 
negotiation 


M 


This information element indicates whether 
the CTM negotiation in user plane was 

successful or not. 


CTM report Ack 


(G)MSC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 
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16.2.47 Prepare_IP_Transport 

This procedure is used to prepare for a bearer establishment when luCS on IP is supported by the MSG. 



Table 16.48: Procedures between (G)MSC server and MGW: Prepare_IP_Transport 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Prepare IP Transport 
(G)MSC-S 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context for 
the IP Access bearer termination. 


Bearer Termination 
Request 


M 


This information element requests a new 
bearer termination for the IP Access bearer to 
be established. 


lu UDP Port Request 


M 


This information element requests the lu UDP 
Port in the MGW 


IP Transport Address 
Request 


M 


This information element requests the IP 
address of the MGW. 


Bearer Characteristics/ 

LJCdi d \j\ idi dOLc^i loliLro 

Requests 


M 


This information element indicates the 

nrpfprrpH ph^iraptpriQtir'Q nf thp hparpr 
|jidC?iic;<J L>i idi doic^i loLiUo \j\ ii it:? ut:?di ci 

connection or requests the MGW to select 
and provide the bearer characteristics. 


Bearer Service 
Characteristics 


C 


This information element indicates the bearer 
service requested by the user. This 
information element is not included if the 
Codec information element is provided. It 
may be included for a data call (see 
3GPP TS 29.007 [37] and 3GPP TS 29.232 


Notify Bearer Event 





This information element requests a 
notification of an established bearer, a 
released bearer, a modified bearer or a 
bearer modification failure. 


Circuit Switched Data 


C 


This information element indicates the PLMN 
bearer capabilities and when applicable the 
user bit rate. This information element shall 

[37] and 3GPP TS 29.232 [6] for a non- 

cnppr'h r'all h\/ thp ^yl^^^ qph/pt nr h\/ thp 
ojJccLfi 1 Lrdii uy LI It; ivioo oci vci , \j\ uy li ic; 

anchor-MSC in case of inter-MSC handover, 
fnr a UMTS rariin arrp*?*? network *5irlp hparpr 
termination. 


Codec 


c 


This information element indicates the 
speech or multimedia coding format to be 
used for the bearer. This information element 

is included for a speech call and may be 
included for a SCUDIF multimedia call 
(see3GPP TS 23.172 [38], 3GPP TS 29.007 
[37] and 3GPP TS 29.232 [6]), for a UMTS 
radio access network side bearer termination. 


Framing Protocol 





This information element indicates the 
framing protocol to be used for the bearer. 


Cellular Text telephony 
modem 


C 


This information element indicates the need 
of CTM function. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Notify termination 
heartbeat 


M 


This information element requests 
termination heartbeat indications. 


Prepare IP 
Transport Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 

executed. 


IP Transport Address 


M 


This information element indicates the IP 
address of the MGW 
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lu UDP Port 


M 


This information element requests the lu UDP 










Port in the MGW 



1 6.2.48 Modify IP Transport Address 

This procedure is used when luCS on IP is supported by the MGW and luUP in transparent mode is configured. 
Table 16.49: Procedures between (G)MSC server and MGW: RNC IP address notification 



Procedure 


Initiated 


Information element 
name 


Information 

element 
required 


Information element description 


IVlodify IP 
Transport Address 


MSC-S 


Context 


M 


This information element indicates the 
context for the IP bearer termination. 


Bearer Termination 


M 


This information element indicates the IP 
bearer termination where the RNC IP 
Address is needed. 


IP Transport address 


M 


This information element indicates the IP 
address of the RNC 


lu UDP Port 


M 


This information element indicates the lu 
UDP Port in the RNC 


Modify IP Address 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the IP 
bearer termination where the command is 
executed. 



16.2.49 Emergency Call Indication 

This procedure is used to indicate that the call is an emergency call. 

Table 16.50: Procedures between (G)MSC server and MGW: Emergency Call Indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Emergency Call 
Indication 


(G)MSC-S 


Context Request 


M 


This information element indicates the 
existing context or requests a new context for 
the bearer termination. 


Emergency Call 
Indicator 


M 


This information element indicates the 
emergency call information 


Emergency Call 
Indication Acl< 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 
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1 6.2.50 Trace Activation 

This procedure is used for activation of a Trace Session in a MGW. 



Table 16.51 : Procedures between (G)MSC server and MGW: Trace Activation 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Trace Activation 


IVISC-S 


Context 


IVI 


This information element indicates the 
context for the command. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination(s) for the command. 


Trace Reference 


c 


Defined in 3GPP TS 32.421 and 3GPP TS 
32.422 


Trace Session 
Recording Reference 


c 


Defined in 3GPP TS 32.421 and 3GPP TS 

32.422 


Triggering Events 


c 


Defined in 3GPP TS 32.421 and 3GPP TS 
32.422 


Trace Depth 


c 


Defined in 3GPP TS 32.421 and 3GPP TS 
32.422 


List of interfaces 





Defined 3GPP TS 32.422 


Trace Activity Control 


M 


This information element indicates the trace 
activation) 


IMSI 


C 


This information element shows the IMSI of 
the traced subscriber. Either IMSI or 
IMEI{SV) must be provided. 


IMEI(SV) 


c 


This information element shows the IMEI(SV) 
of the traced equipment. Either IMSI or 
IMEI(SV) must be provided. 


Notify Trace Activation 
result 





This information element requests a 
notification of the result of the trace 
activation. 


Trace Activation 
Reply 


iVIGW 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



16.2.51 Trace Deactivation 

This procedure is used for deactivation of a Trace Session in a MGW.. 

Table 16.52: Procedures between (G)MSC server and MGW: Trace Deactivation 



Procedure 


initiated 


information element 
name 


information 
element 
required 


information element description 


Trace Deactivation 


MSC-S 


Context 


M 


This information element indicates the 
context for the command. 


Bearer Termination 


M 


This information element indicates the bearer 
termination(s) for the command. 


Trace Reference 


M 


Defined in 3GPP TS 32.421 and 3GPP TS 
32.422 


Trace Activity Control 


M 


This information element indicates the trace 
deactivation 


Trace Deactivation 
Reply 


MGW 


Context 


M 


This information element indicates the 

context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed 
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1 6.2.52 Trace Activation result notification 

This procedure is used for informing the MSG Server about the result of the Trace Session Activation. 



Table 16.53: Procedures between MGW and (G)MSC Server: Trace Activation result notification 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Trace Activation 
result notification 


MGW 


Context 


IVI 


This information element indicates the 
context for the command 


Bearer Termination 


M 


This information element indicates the bearer 
termination(s) for the command 


Result 


M 


This information element defines the result of 
the Trace Session Activation 


Trace Activation 
result notification 
Ack 


IVISC-S 


Context 


M 


This information element indicates the 
context where the command was executed 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



1 6.2.53 Continuity Clieck Tone 

This procedure is used by the (G)MSC to order the MGW to generate a continuity check tone at a TDM termination and 
to inform the (G)MSC about the result of the continuity check as soon as the continuity check tone is received or a time- 
out occurs. 

Table 16.54: Continuity Checic Tone procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity Check 
Tone 


(G)MSC 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDM Termination 


M 


This information element indicates the 
bearer termination 






Request for continuity 
tone sending 


M 


This information request the MGW to apply 
the continuity check procedure on the 
indicated TDM termination 






Request for continuity 
check tone detection 


M 


This information request the MGW to 
inform of result of the continuity check 
procedure on the indicated TDM 
termination 


Continuity Check 
Tone Ack 


IMGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



1 6.2.54 Continuity Clieck Verify 

This procedure is used by the MGW to indicate towards the (G)MSC that the continuity check at a TDM termination 
has been completed and to return the result of the check: success or failure. 
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Table 16.55: Continuity Cliecic Verify procedure 



Procedure 


initiated 


information eiement 
name 


Information 
element 
required 


Information element description 


Continuity check 
Verify 


MGW 


Context/t 


M 


This information element indicates the 
context where the command was executed. 






TDI^ Termination 


M 


This information element indicates the 
TDM termination involved in the procedure 






Outcome of the 
continuity check 


M 


This information element indicates the 
outcome of the continuity check 
(successful/unsuccessful) 


Continuity Check 
Verify Ack 


(G)MSC 


Context 


M 


This information element indicates the 
context where the command was executed. 



1 6.2.55 Continuity Clieck Response 

This procedure is used by the (G)MSC to order the MGW to loop back an incoming continuity check tone at a TDM 
termination. 

Table 16.56: Continuity Check Response procedure 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Continuity Check 
Response 


(G)MSC 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 






TDM Termination 


M 


This information element indicates the 
bearer termination 






Request for loop back 
of the continuity tone 


M 


This information request the MGW to loop 
back the continuity check tone on the 
indicated TDM termination 


Continuity Check 
Response Ack 


IIVIGW 


Context 


M 


This information element indicates the 
context where the command was executed. 



16.2.56 RateCliange 

This procedure is used to notify that the CS data rate should be changed. 

Table 16.57: Procedures between (G)MSC server and MGW: Rate Change 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Rate Change 


IVIGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the rate change is 
required. 


Rate 


M 


This information element notifies the current 
rate. 


Rate Change Ack 


(G)IVISC-S 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.57 Bearer Modifed 

This procedure is used to notify the modified bearer. 



Table 16.2.57/1 : Procedures between (G)MSC server and MGW: Bearer Modified 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer Modified 


MGW 


Context 


M 


Tliis information element Indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This Information element Indicates the bearer 
termination where the bearer was modified. 


Bearer Modified 


M 


This information element notifies a bearer 
modification. 


Bearer Modified 
Acl< 


(G)MSC-S 


Context 


M 


This Information element Indicates the 
context where the command was executed. 


Bearer Termination 


M 


This Information element indicates the bearer 
termination where the command was 
executed. 



16.2.58 Bearer Modification Failed 

This procedure is used to notify the failed bearer modification. 



Table 16.2.58/1: Procedures between (G)MSC server and MGW: Bearer Modification failed 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Bearer 
Modification Failed 


MGW 


Context 


M 


This Information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This Information element Indicates the bearer 
termination where the bearer modification 
failed. 


Bearer Modification 
failure 


M 


This information element notifies a bearer 
modification failure 


Bearer 
Modification Failed 
Ack 


(G)MSC-S 


Context 


M 


This Information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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16.2.59 Termination heartbeat indication 

This procedure is used to report indication of hanging termination. 



Table 16.2.59/1: Procedures between (G)MSC server and MGW: Hanging termination indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
heartbeat 
indication 


IVIGW 


Context 


IVI 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


IVI 


This information element indicates the bearer 
termination for which the termination 
heartbeat is reported. 


Termination heartbeat 


IVI 


Hanging termination event as defined in 
3GPP TS 29.232 [6]. 


Termination 
heartbeat 
indication Ack 


(G)MSC-S 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the Bearer 
Termination where the command was 
executed. 



1 6.2.60 Inactivity timeout activation 

This procedure is used to activate the inactivity timeout mechanism. 

Table 16.2.60/1 : Procedures between (G)MSC server and MGW: Inactivity timeout activation 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Inactivity timeout 
activation 


(G)MSC-S 


Context 


IVI 


This information element indicates the 
context for the command. 


Root Termination 


M 


This information element indicates that root 
termination is where the inactivity timeout 
mechanism is activated. 


Inactivity Timeout 


M 


Inactivity timeout event as defined in 
3GPP TS 29.232 [6]. 


Inactivity timeout 
activation Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Root Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 
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1 6.2.61 Inactivity timeout indication 

This procedure is used by MGW to report indication of inactivity timeout to MGC. 



Table 16.2.61/1 : Procedures between (G)MSC server and MGW: Inactivity timeout indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Inactivity timeout 
indication 


MGW 


Context 


IVI 


This information element indicates the 
context for the command. 


ROOT Termination 


M 


This information element indicates that root 
termination is where the inactivity timeout 
mechanism was activated. 


Inactivity Timeout 


M 


Inactivity timeout event as defined in 
3GPP TS 29.232 [6]. 


Inactivity timeout 
indication Ack 


(G)MSC-S 


Context 


IVI 


This information element indicates the 
context where the command was executed. 


ROOT Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 



16.2.62 Reserve RTP Connection Point 

This procedure is used to reserve an RTP bearer termination. 
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Table 16.2.62.1: Reserve RTP Connection Point 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Reserve RTP 
Connection Point 


(G)IVISC- 
Server 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new 

context for the bearer termination. 


Termination 
Request 


M 


This information element requests a new 
termination for the bearer to be 
established. 


IP Interface 





This information element specifies the 
type of external interface to be used for 
the IP termination (e.g. AolP). 


Local IP Resources 


M 


This information element indicates the 
resource(s) (e.g. codec, auxiliary payload 
types) for which the MGW shall be 

prepared to receive user data, 


ReserveValue 


C 


This information element indicates if 
multiple local resources are to be 
reserved. 

This information element shall be 
included if a speech codec and auxiliary 
payload types are required. 


Local Connection 
Address Request 


M 


This information element requests an IP 
address and port number on the MGW 
that the remote end can send user plane 
data to. 


Notify termination 
heartbeat 


M 


This information element requests 

termination heartbeat indications. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Cellular Text 
telephony modem 


c 


This information element indicates the 
need of CTM function. 
(NOTE 1) 


Number of desired 
listener context 
terminations 





This information element indicates the 
number of desired terminations for a 
listener context in a VGCS or VBS call. It 
should be included in the first ADD 
request which establishes a Listener 
context. 
(NOTE 1) 


Circuit Switched 
Data 


c 


This information element indicates the 
PLMN bearer capabilities and when 

applicable GSM channel coding. This 
information element shall be included 
according to 3GPP TS 29.007 [37] and 
3GPP TS 29.232 [6] for a non-speech / 
non SCUDIF multimedia call (see 3GPP 
TS 23.172 [20]) by the MSC server, or by 
the anchor-MSC in case of inter-MSC 
handover, for an anchor MGW network 
termination. 


IP Version 


c 


This information element indicates the 
version of the internet protocol to be 
applied at the termination for the user 
plane. This is required for IP address 
translation. (NOTE 4) 


DiffServ Code Point 


o 


This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. (NOTE 4) 
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DiffServ Tagging 
Behaviour 





This information element indicates 
whether the Diffserv code point in the IP 
header in packets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 
(NOTE 4) 


Remote Source 
Address Filtering 





This information element indicates that 
remote source address filtering is 
required. (NOTE 4) 


Remote Source 
Address Mask 


C 


This information element provides 
information on the valid remote source 
addresses. This may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. (NOTE 4) 


Remote Source 
Port Filtering 





This information element indicates that 
remote source port filtering is required. 
(NOTE 4) 


Remote Source 
Port 


C 


This information element identifies the 
valid remote source port. This may be 
included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (NOTE 2, NOTE 4) 


Remote Source 
Port Range 


C 


This information element identifies a 
range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 2, NOTE 4) 


Media Inactivity 
Detection Required 





This information element indicates that 
detection of inactive media flows is 
required. (NOTE 4) 


Inactivity Detection 
Time 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. (NOTE 4) 


Inactivity Detection 
Direction 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. (NOTE 4) 


RTCP handling 





Indicates whether or not the CS-MGW 
shall reserve a port for an RTCP flow. 

(NOTE 4) 


Traffic Policing 
Required 





This information element indicates that 
policing of the media flow is required. 
(NOTE 4) 


Peak Data Rate 





This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 3, NOTE 4) 


Sustainable Data 
Rate 





This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 3, NOTE 4) 


Delay Variation 
Tolerance 





This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 

corresponding media stream. (NOTE 4) 


Maximum Burst 
Size 


c 


This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. (NOTE 4) 
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Reserve RTP 


MGW 


Context 


M 


This information element indicates the 


Connection Point 








context where the command was 


Ack 








executed. 






Termination 


M 


This information element indicates the 
termination where the command was 

executed. 






Local IP Resources 


M 


This information element indicates the 
resources that the MGW has reserved to 
receive the user plane data from the 
remote peer. 






Local Connection 


M 


This information element indicates the IP 






Address 




address and port on the MGW that shall 
receive user plane data from the remote 
peer. 



NOTE 1 : Only applies for Access side terminations 

NOTE 2: Remote Source Port and Remote Source Port Range are mutually exclusive. 

NOTE 3: At least one of these lEs shall be present when policing is required. 

NOTE 4: This information element is used for border control functions as defined in Annex A of 3GPP TS 29.235 [44] 



16.2.63 Configure RTP Connection Point 

This procedure is used to configure or reconfigure an RTP bearer termination. 
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Table 16.2.63.1: Configure RTP Connection Point Procedure 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


information element description 


Configure RTP 
Connection Point 


(G)IVISC- 
Server 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
existing bearer termination. 


IP Interface 





This information element specifies the 
type of external interface to be used for 
the IP termination (e.g. AolP). 


Local IP Resources 





This information element indicates the 
resources (e.g. codec, auxiliary payload 
types) that the MGW may use on the 
reception of user plane data. 


Remote IP 
Resources 





This information element indicates the 

resources (e.g. codec, auxiliary payload 
types) that the IVIGW may send user 
plane data to. 


Local Connection 
Address 





This information element indicates the IP 
address and port on the MGW that the 
remote peer can send user plane data to. 


Remote 
Connection 
Address 





This information element indicates the IP 
address and port that the MGW can send 
user plane data to. 


Reserve Value 


c 


This information element indicates if 
multiple resources are to be reserved. 
This information element shall be 
included if a speech codec and auxiliary 
payload types are required. 


Cellular Text 
telephony modem 


c 


This information element indicates the 
need of CTM function. 
(NOTE 1) 


Number of desired 
listener context 
terminations 





This information element indicates the 
number of desired terminations for a 
listener context in a VGCS or VBS call. It 
should be included in the first ADD 
request which establishes a Listener 
context. 
(NOTE 1) 


Circuit Switched 
Data 





This information element indicates the 
PLMN bearer capabilities and when 
applicable GSM channel coding. This 
information element shall be included 
according to 3GPP TS 29.007 [37] and 
3GPP TS 29.232 [6] for a non-speech/ 
non SCUDIF multimedia call by the MSC 
server, or by the anchor-MSC in case of 
inter-MSC handover for an anchor MGW 
networl< termination. 


DiffServ Code Point 





This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. (NOTE 4) 


DiffServ Tagging 
Behaviour 





This information element indicates 
whether the Diffserv code point in the IP 
header in pacl<ets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 
(NOTE 4) 


Remote Source 
Address Filtering 





This information element indicates that 
remote source address filtering is 
required. (NOTE 4) 
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Remote Source 
Address Mask 


C 


Tliis information element provides 
information on tine valid remote source 
addresses. Ttiis may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. (NOTE 4) 


Remote Source 
Port Filtering 





This information element indicates that 
remote source port filtering is required. 
(NOTE 4) 


Remote Source 
Port 


C 


This information element identifies the 
valid remote source port. This may be 

included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (NOTE 2, NOTE 4) 


Remote Source 
Port Range 


C 


This information element identifies a 
range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 2, NOTE 4) 


IVIedia Inactivity 
Detection Required 





This information element indicates that 
detection of inactive media flows is 
required. (NOTE 4) 


Inactivity Detection 
Time 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. (NOTE 4) 


Inactivity Detection 
Direction 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. (NOTE 4) 


RTCP handling 





Indicates whether or not the GS-MGW 
shall reserve a port for an RTCP flow. 
(NOTE 4) 


Traffic Policing 
Required 





This information element indicates that 
policing of the media flow is required. 
(NOTE 4) 


Peak Data Rate 





This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 3, NOTE 4) 


Sustainable Data 
Rate 





This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 3, NOTE 4) 


Delay Variation 
Tolerance 





This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 
corresponding media stream. (NOTE 4) 


Maximum Burst 
Size 


c 


This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. (NOTE 4) 


Configure RTP 
Connection Point 
Ack 


MGW 


Context 


M 


This information element indicates the 
context where the command was 
executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 


Local IP Resource 





This information element indicates the 
resources that the MGW has reserved to 
receive the user plane data from the far 
end. 
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Remote IP 
Resource 


C 


This information element indicates the 
resource (i.e. codec) that the MGW shall 
use to send user data to. Shall be 
present If corresponding IE is present in 
the request. 


Local Connection 
Address 





This information element indicates the IP 
address and port on the MGW that the 
remote end can send user plane data to. 


Remote 
Connection 
Address 


C 


This information element indicates the IP 
address and port that the MGW can send 
user plane data to. Shall be present if 
corresponding IE is present in the 
request. 


NOTE 1 
NOTE 2 
NOTE 3 
NOTE 4 


Only applies for Access side terminations 

Remote Source Port and Remote Source Port Range are mutually exclusive. 
At least one of these lEs shall be present when policing is required. 

This information element is used for border control functions as defined in Annex A of 3GPP TS 29.235 [44] 



16.2.64 Reserve and Configure RTP Connection Point 

This procedure is used to reserve and configure multimedia-processing resources for an RTP termination. 

Table 16.2.64.1: Reserve and Configure RTP Connection Point 



Procedure 


initiated 


information eiement 
name 


Information 
element 
required 


Information element description 


Reserve and 
Configure RTP 
Connection Point 


(G)MSC- 
Server 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context 
for the bearer termination. 


Termination/ 
Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a 
new termination for the bearer to be 

established. 


IP Interface 


O 


This information element specifies the used 
interface type for the IP termination (e.g. 
NbolP). 


Local IP Resources 


M 


This information element indicates the 
resource(s) (e.g. codec, auxiliary payload 
types) for which the MGW shall be prepared 
to receive user data, 


Remote IP Resources 


M 


This information element indicates the 
resources (e.g. codec, auxiliary payload 
types) that the MGW shall use to send user 
data. 


Reserve Value 


C 


This information element indicates if multiple 
IP resources are to be reserved. This 
information element shall be included if a 
speech codec and auxiliary payload types 
are required. 


Cellular Text 
telephony modem 


C 


This information element indicates the need 
of CTM function. 
(NOTE 1) 
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Remote Connection 
Address 


M 


This information element indicates the IP 
address and ports of the remote party that 
the MGW can send user plane data to. 


Notify termination 
heartbeat 


M 


This information element requests 
termination heartbeat indications. 


Notify Released 
Bearer 





This information element requests a 
notification of a released bearer. 


IP Realm Identifier 





This information element indicates the IP 
realm of the IP termination. 


Circuit Switched Data 





This information element indicates the 
PLIVIN bearer capabilities and when 
applicable GSM channel coding. This 
information element shall be included 
according to 3GPP TS 29.007 [6] and 3GPP 
TS 29.232 [8] for a non-speech / non 
SCUDIF multimedia call (see 3GPP TS 
23.1 72 [20]) by the MSC server, or by the 
anchor-MSC in case of inter-MSC handover, 
for an anchor MGW network termination. 


IP Version 


C 


This information element indicates the 
version of the internet protocol to be applied 
at the termination for the user plane. This is 
required for IP address translation. (NOTE 
4) 


DiffServ Code Point 


O 


This information element indicates a specific 
DiffServ code point to be used in the IP 
header in packets sent on the IP 
termination. (NOTE 4) 


DiffServ Tagging 
Behaviour 





This information element indicates whether 
the Diffserv code point in the IP header in 
packets sent on the IP termination should be 
copied from the received value or set to a 
specific value. (NOTE 4) 


Remote Source 
Address Filtering 





This information element indicates that 
remote source address filtering is required. 
(NOTE 4) 


Remote Source 
Address IVIask 


C 


This information element provides 
information on the valid remote source 
addresses. This may be included if remote 
source address filtering is included. It shall 
not be included if remote source address 
filtering is not included. (NOTE 4) 


Remote Source Port 
Filtering 





This information element indicates that 
remote source port filtering is required. 
(NOTE 4) 


Remote Source Port 


C 


This information element identifies the valid 
remote source port. This may be included if 
remote source port filtering is included. It 

shall not be included if remote source port 
filtering is not included. (NOTE 2, NOTE 4) 


Remote Source Port 
Range 


C 


This information element identifies a range 
of valid remote source ports. This may be 
included if remote source port filtering is 

included. It shall not be included if remote 
source port filtering is not included. (NOTE 
2, NOTE 4) 


Media Inactivity 
Detection Required 





This information element indicates that 
detection of inactive media flows is required. 
(NOTE 4) 


Inactivity Detection 
Time 


C 


This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection time. 
(NOTE 4) 


Inactivity Detection 
Direction 


C 


This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection direction. 
(NOTE 4) 
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RTCP handling 





Indicates whether or not the CS-IVIGW shall 
reserve a port for an RTCP flow. (NOTE 4) 


Traffic Policing 
Required 





This information element indicates that 
policing of the media flow is required. 
(NOTE 4) 


Peak Data Rate 





This information element may be present if 
Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 3, NOTE 4) 


Sustainable Data 
Rate 





This information element may be present if 
Policing is required and specifies the 
permissible sustainable data rate for a 

media stream. (NOTE 3, NOTE 4) 


Delay Variation 
Tolerance 





This information element may be present if 
Policing on Peak Data Rate is required and 
specifies the maximum expected delay 
variation tolerance for the corresponding 
media stream. (NOTE 4) 


Maximum Burst Size 


C 


This information element shall be present if 
Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the corresponding 
media stream. (NOTE 4) 


Reserve and 

Configure RTP 
Connection Point 


MGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 


Local IP Resources 


M 


This information element indicates the 

resources that the MGW has reserved to 
receive the user plane data from the remote 
side. 


Remote IP Resources 


M 


This information element indicates the 
resource (i.e. codec) that the MGW shall use 

to send user data. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address and port on the MGW that shall 
receive user plane data. 


NOTE 1 
NOTE 2 
NOTES 
NOTE 4 


Only applies for Access side terminations 

Remote Source Port and Remote Source Port Range are mutually exclusive. 
At least one of these lEs shall be present when policing is required. 

This information element is used for border control functions as defined in Annex A of 3GPP TS 29.235 [44] 



1 6.2.65 Realm Availability Change - Activation 

This procedure is used to activate the realm availability notification mechanism. 



Table 16.2.65.1: Realm Availability Change - Activation 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Realm Availability 
Change - Activate 


(G)MSC- 
Server 


Context 


M 


This information element indicates the NULL 
context. 


Root Termination 


M 


This information element indicates that root 
termination is where the realm availability 
change notification mechanism is activated. 


Realm Availability 
Change Activate 


M 


This information element requests to activate 
the realm availability change notification 
mechanism. 


Realm Availability 
Change -Activate 
Ack 


MGW 


Context 


M 


This information element indicates the NULL 

context. 


Root Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 
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NOTE: This procedure is used for border control functions as defined in Annex A of 3GPP TS 29.235 [44] 



1 6.2.66 Realm Availability Change - Indication 

This procedure is used to inform the (G)MSC-Server that there has been a change to the list of currently available 
realms. 



Table 16.2.66.1 : Realm Availability Change - Indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Realm Availability 
Change - 
Indication 


MGW 


Context 


M 


This information element indicates the NULL 
context. 


Root Termination 


M 


This information element indicates that root 
termination is where the realm availability 
change notification mechanism was 
activated. 


Changes to Realm 
Availability 


M 


This information element indicates the 
changes to the list of available realms. 


Realm Availability 
Change - 
Indication Ack 


(G)MSC- 
Server 


Context 


M 


This information element indicates the NULL 
context. 


Root Termination 


M 


This information element indicates that root 
termination is where the command was 
executed. 


NOTE: This procedure is used for border control functions as defined in Annex A of 3GPP TS 29.235 [44] 



17 Bearer Redirect 

The BICC [22] Bearer Redirect mechanism may be used for optimising the bearer path when an endpoint of a call 
changes due to the operation of an application layer service. 



1 7.1 Example of use of Bearer Redirect with Call Forwarding on 
No Reply (CFNRy) 



Before CFNRy: 
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GMSC-S 





CTXl 
MGWG 



MSC-S B 





CTX2 
MGWB 



Figure 17.1 B: CFNRy and Bearer Redirect (Network model) 



Figure 17.2 shows the message sequence example for the call forwarding on no reply with Bearer Redirect. In the 
example, after the call and the bearer towards the access have been released MSC server A requests the MGW A to 
remove the bearer termination for the served mobile subscriber. MSC server A requests the GMSC server to redirect the 
bearer to the forwarded to subscriber (interactions towards the access are not shown), using MSC server A as a call 
control anchor. Once the bearer towards MGW B is established the GMSC server instructs MGW G to connect the 
incoming bearer to the new bearer (towards MGW B) and informs MSC server A. Once informed that the new bearer 
has been established MSC server A instructs the GMSC server to removes the old bearer termination (towards 
MGW A). 
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Figure 17.2: Information flow for CFNRy withi Bearer Redirect (message sequence chiart) 
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1 8 (G)MSC MGW Tandeming 

In all call flow examples a (G)MSC server may tandem (either during call setup or during an active call, as part of an 
application layer service invocation) the bearer through one or more MGWs under its control, in order to access bearer 
resources which may be distributed over a number of specialised MGWs. 



18.1 Example of use of MSG MGW Tandeming during call setup 
to provide bearer access to specialised MGW resources 



Before MGW tandeming: 



GMSC-S 





MSC-S A 






CTX2 
MGWB 



Figure 18.1 A: MSC before MGW Tandeming during call setup to provide bearer access 
to specialised MGW resources (Network model) 



After MGW tandeming: 




Figure 18.1 B: MSC after MGW Tandeming during call setup to provide bearer access 
to specialised MGW resources (Network model) 

The figure 18.2 below shows the message sequence example for MSC MGW Tandeming during call setup to provide 
bearer access to specialised MGW resources. In the example, after the signalling towards MSC server A and the bearer 
towards the MGW B is established, MSC server A requests the MGW B to tandem the bearer and terminate it at MGW 
C, where specialised bearer resources which are not available at MGW B may be provided. 



ETSI 



3GPP TS 23.205 version 9.2.0 Release 9 



264 



ETSI TS 123 205 V9.2.0 (2011-04) 



GMSC-S 
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\DD.request ($) 
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Figure 18.2: MSC MGWTandeming during call setup to provide bearer access 
to specialised MGW resources (message sequence chart) 



19 Timers for bearer independent CS core network 

Table 19.1 : Timers for bearer independent CS core network 



Timer Identity 


Timer value 


Timer started 


Timer stopped 


Timer expiry 


Start_Bearer_E 
stablishment 


1-14 seconds 


Paging procedure is started. 
Applied only if network side 
bearer establishment is 
delayed until paging 
procedure is completed. 


Paging procedure is 
completed or optionally 
when Call Confirmed 
message is received. 


The network side bearer 
establishment is started. 



20 IVIultiple IP Realms 

Figure 20/1 shows a scenario to support multiple IP realms when the lu interface or Nb interface supports IP bearer. 




MGW 



Logical Port1 



Logical Ports 




Logical Port2 



Logical Port4 




Figure 20/1 Multiple IP realms scenario for lu or Nb interface 
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The RANI, RAN2, CNl and CN2 represents separate IP realm. The definition of IP reahn is specified in IETF RFC 
2663 [41]. 

The Logical Port 1/2/3/4 represents a logical port connected with the IP realm in the MGW. 

For estabUshing session when multiple IP realms are used in the MGW, the MGC may indicate the IP realm identifier to 
the MGW. The MGW shall assign the IP termination in the IP realm indicated. 

A default IP realm may be configured such that if the MGW has not received the IP realm identifier and the MGW 
supports multiple IP realms then the default IP realm shall be used. 

If the MGW does not support the option to indicate an IP realm then it is free to select an IP port as per implementation 
permitted in previous releases. 
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